Checklist de IA lista para producción
Una checklist corta para equipos que ya tienen una función LLM, RAG o agente funcionando en demo y necesitan decidir si puede enfrentar usuarios reales. Si varias respuestas no están claras, la función no está bloqueada: está sin medir.
Las doce preguntas
- ¿Puede reproducir cualquier respuesta que dio el sistema la semana pasada, incluyendo fuentes, prompt, modelo y versión del índice?
- ¿Tiene un set fijo de evaluación que corre antes de publicar cambios de prompt, modelo o retrieval?
- ¿Un usuario puede recibir una respuesta construida con un documento que no puede abrir?
- ¿Conoce el costo por request, por cliente y por función, incluyendo peores casos de input?
- ¿Qué hace el producto cuando el modelo está lento, caído, inseguro o sin evidencia?
- ¿Un agente puede ejecutar dos veces la misma acción de escritura después de un timeout o reintento?
- ¿Las acciones destructivas o de alto impacto tienen confirmación, límites y atribución?
- ¿Las alucinaciones se registran como fallas de producto, no como anécdotas de soporte?
- ¿Soporte o ingeniería pueden inspeccionar qué se recuperó y por qué ante una respuesta disputada?
- ¿Cada salida registra versiones de modelo, prompt, índice y configuración?
- ¿Los logs se conservan lo suficiente para responder preguntas enterprise, de auditoría o de incidente?
- ¿Hay un responsable claro de regresiones de calidad, costo y seguridad después del lanzamiento?
Cómo leer las respuestas
Mayormente sí
La función tiene la forma básica de un sistema de IA operable. Lo siguiente suele ser hardening, control de costo y mejor cobertura de evaluación.
Respuestas mezcladas
Es el caso común. La función puede avanzar, pero las respuestas poco claras deberían volverse backlog explícito antes del lanzamiento.
Mayormente no
La demo puede ser útil, pero el riesgo de producción sigue invisible. Conviene publicar con límites estrechos, o revisar la arquitectura primero.
No se sabe
No saber es un riesgo propio. Si nadie puede responder una pregunta, probablemente el sistema todavía no registra suficiente evidencia.
Dónde suelen aparecer los huecos
Retrieval
Se guarda la respuesta, pero no las fuentes exactas que la produjeron. Repetir la pregunta contra un índice cambiado prueba poco.
Permisos
Los controles de acceso ocurren después del retrieval, o solo en la interfaz. El modelo puede haber visto datos que el usuario no debería ver.
Evaluación
No hay benchmark estable, así que las mejoras de prompt se juzgan con unos pocos ejemplos probados ese día.
Operación
Latencia, costo y comportamiento ante fallas no se tratan como requisitos de producto hasta que un cliente encuentra el borde.
Si necesita una revisión
- Elegir el flujo de IA donde equivocarse cuesta más
- Enviar unas líneas sobre sistema, fuentes de datos, usuarios y fecha
- Le decimos si una revisión de 10 días hábiles encaja
- Si encaja, la salida es un informe escrito con riesgos, huecos de evidencia y plan de 30 días
Preguntas que esto abre
¿La checklist alcanza por sí sola?
No. Es una forma de notar riesgo antes de que se vuelva incidente. La respuesta detallada depende de la implementación y del contexto de negocio.
¿Toda función de IA necesita todo esto?
No. Helpers internos y funciones de bajo riesgo necesitan menos maquinaria que agentes frente a clientes o sistemas que tocan dinero, datos personales o workflows enterprise.
¿Esto debería bloquear el lanzamiento?
No automáticamente. Debería moldear el lanzamiento: alcance más estrecho, límites, monitoreo, fallback o revisión antes de abrirlo más.
¿Cuál es el mejor momento para correr esto?
Antes de un lanzamiento público, rollout enterprise, revisión de compliance, due diligence de inversión o reescritura del pipeline de IA.
Iniciar una conversación
Cuéntenos qué están construyendo, o qué se está rompiendo. Va a recibir una respuesta directa de un ingeniero, no un libreto de ventas.