Separá el ensayo del trabajo real
Prepará un entorno de prueba que no envíe mensajes a clientes, no cambie registros productivos y no dispare pagos. Si no existe un entorno separado, agregá una barrera explícita para impedir que el ensayo alcance esos sistemas.
Usá nombres, teléfonos y correos inventados. No alcanza con cambiar el nombre de una persona si todavía quedan números, conversaciones, identificadores o datos que permitan reconocerla. Tampoco copies credenciales reales en capturas, ejemplos o registros de prueba.
Armá casos variados antes de ejecutar
- Entrada válida: todos los campos obligatorios tienen formato correcto.
- Dato ausente: falta un campo o llega vacío.
- Formato inesperado: caracteres, fecha o número no siguen la forma esperada.
- Evento repetido: el mismo envío o aviso aparece dos veces.
- Respuesta lenta: el servicio externo tarda o agota el tiempo.
- Rechazo: el usuario o sistema receptor niega el acceso.
- Excepción operativa: el caso necesita criterio o autorización humana.
Para cada caso escribí el resultado esperado antes de mirar la ejecución. Eso evita llamar “éxito” a una salida que simplemente parece razonable.
Convertí cada caso en una prueba repetible
Una prueba es más útil cuando otra persona puede repetirla y comprobar el mismo resultado. Registrá el identificador ficticio de entrada, la condición que estás probando, el resultado esperado, lo que ocurrió y si necesitó intervención.
- Dato ausente: usá un registro sintético sin un campo obligatorio. Esperá que quede marcado para revisión; no que el flujo complete el valor por su cuenta.
- Duplicado: enviá dos veces el mismo evento de prueba. Esperá un solo registro o una señal clara para resolver la repetición.
- Falla de conexión: simulá que el destino no responde. Esperá un error visible y un modo definido de retomar el trabajo, no una confirmación falsa de éxito.
- Acción externa: comprobá que el ensayo solo alcance una bandeja o destino controlado y que no contacte a una persona real.
Podés copiar este formato para cada ejecución: ID de prueba · condición · resultado esperado · resultado observado · aprobado / revisar · responsable del seguimiento. Usá identificadores como “DEMO-01” y datos inventados, no capturas de registros reales.
Revisá lo que se guarda y lo que se comunica
Comprobá que el registro aparezca una sola vez, que los campos se asignen correctamente y que el sistema no copie datos a lugares innecesarios. Revisá el contenido y el destinatario de cualquier notificación. Durante las pruebas, usá bandejas o destinos controlados.
Si el flujo usa un modelo de IA, tratá sus entradas y salidas como datos que pueden ser incompletos o incorrectos. Definí qué información no debe enviarse al modelo, qué respuestas requieren revisión y cómo se detiene una acción insegura. NIST presenta el AI Risk Management Framework como un marco voluntario para incorporar consideraciones de confianza durante el diseño, uso y evaluación de sistemas de IA; no reemplaza la revisión del caso concreto (NIST AI RMF).
Probá fallas y recuperaciones
- Provocá una respuesta de error controlada y confirmá que quede visible para el responsable.
- Verificá que un reintento no duplique una acción externa.
- Comprobá que los registros permitan entender el fallo sin guardar datos sensibles innecesarios.
- Definí quién puede pausar el flujo y cómo volver al procedimiento manual.
- Documentá la versión aprobada y los cambios que requieren una nueva prueba.
Si el sistema integra IA generativa, revisá además los riesgos específicos de esa tecnología. OWASP publica una lista de riesgos para aplicaciones con modelos de lenguaje, incluyendo la exposición de información sensible y la manipulación de entradas (OWASP Top 10 para aplicaciones LLM).
Checklist para autorizar un piloto
- La persona responsable conoce qué activa el flujo.
- Los ensayos usan datos ficticios o expresamente autorizados.
- Los resultados y las excepciones se pueden revisar.
- Los reintentos no repiten acciones irreversibles.
- Existe un contacto y un procedimiento de pausa.
- Las comunicaciones externas tienen contenido, destinatario y permiso adecuados.
- El equipo sabe qué límites tiene la automatización y cuándo debe intervenir.
Este checklist no certifica seguridad ni cumplimiento. Es un punto de partida para una revisión operativa proporcional al riesgo. Para conversar sobre un flujo concreto, contactanos.