Cómo evaluar una propuesta de IA

Una propuesta de IA puede tener una demostración convincente y seguir dejando sin resolver lo importante: qué pasa cuando faltan datos, quién autoriza una acción y cuánto trabajo queda para tu equipo. Antes de contratar, yo buscaría respuestas verificables, no una lista de modelos y herramientas.

No hace falta dominar la arquitectura. Sí hace falta poder decidir qué se compra, cómo se comprobará que funciona y cuándo conviene detenerse.

Primero: ¿hace falta un agente?

Pide que la propuesta describa el proceso actual: entradas, decisiones, responsables y resultado esperado. Después, que compare alternativas.

Si los pasos y las reglas son estables, una automatización convencional puede bastar. Si solo necesitas clasificar mensajes o extraer campos, quizá alcance con una llamada a un modelo dentro de un flujo fijo. Un agente tiene más sentido cuando debe elegir pasos o herramientas según lo que encuentre; esa flexibilidad también exige más controles.

Mi pregunta sería: ¿qué decisión necesita tomar el sistema que no podamos resolver con reglas explícitas? Si no hay una respuesta concreta, pediría una solución más sencilla como referencia de costo y complejidad.

Prueba el trabajo real, no solo la demostración

Una demo enseña que algo es posible. Una evaluación debe mostrar dónde funciona y dónde falla.

Acuerda un conjunto de tareas representativas antes de ajustar el sistema: solicitudes frecuentes, casos ambiguos, información incompleta y situaciones que debe rechazar. Usa datos anonimizados o autorizados y reserva algunos casos para la evaluación final.

Compara contra el proceso actual o una alternativa sencilla, con los mismos casos. No midas solo rapidez: incluye corrección, tiempo de revisión humana, errores críticos y costo por tarea aceptada. Define quién revisará las respuestas y con qué rúbrica. Si el equipo corrige casi todo, ese esfuerzo también cuenta.

Pregunta por fallos, recuperación y aprobación

Yo pediría recorrer un fallo concreto de principio a fin:

• Si una herramienta no responde, ¿se reintenta, se pausa o se deriva a una persona?
• Si una operación se repite, ¿cómo se evita enviar dos mensajes o crear dos registros?
• Si falta evidencia o hay fuentes contradictorias, ¿el sistema pide aclaraciones o inventa una respuesta?
• ¿Qué acciones requieren aprobación humana y qué información ve quien aprueba?
• ¿Cómo se detiene la ejecución, se inspecciona lo ocurrido y se retoma sin repetir acciones ya realizadas?

«Hay un humano en el circuito» no basta. La propuesta debe señalar el punto de aprobación y qué queda bloqueado hasta recibirla. Una acción irreversible necesita un tratamiento distinto al de un borrador editable.

Delimita el acceso a los datos

Pide un mapa sencillo: qué fuentes lee, dónde escribe y qué información sale hacia proveedores externos. Distingue permisos de lectura y escritura; no entregues acceso administrativo por comodidad.

También deben quedar claros la retención de conversaciones y registros, su eliminación, el acceso del proveedor y la separación entre clientes o equipos. El contenido de un documento no debería poder ampliar los permisos del sistema. Pregunta cómo se prueba ese límite, no solo qué dice el prompt.

Exige una arquitectura explicable, no una arquitectura de moda

En Ketzai Agent, el sistema que desarrolla mi equipo en Ketzai, una arquitectura modular permite atender distintas tareas educativas con una coordinación compartida. Lidero el trabajo del equipo en la orquestación, el enrutamiento y el núcleo de ejecución que conecta contexto, generación y revisión, junto con las herramientas de pruebas y evaluación.

Ese diseño responde a distintas tareas educativas que comparten coordinación. No es una receta para todos los proyectos. Lo que pediría en cualquier propuesta es la misma claridad: cómo se organiza el trabajo, quién controla cada paso y cómo se verifica cada cambio.

Define el piloto antes de firmar el contrato

El piloto debería entregar más que una demo: alcance documentado, casos de prueba, resultados con fallos incluidos, código y configuración acordados, instrucciones de operación y una recomendación de continuar o parar.

Esta lista es ilustrativa, no un resultado obtenido ni un umbral universal:

• Evaluar 30 solicitudes acordadas, incluyendo entradas incompletas y fallos de herramientas.
• Aceptar al menos 27 con la rúbrica definida; registrar correcciones y tiempo de revisión.
• Bloquear todas las escrituras sin autorización y derivar los casos fuera de alcance.
• Mantener el costo por tarea y la latencia dentro de límites acordados antes de empezar.
• No pasar a producción si falla un control crítico, aunque la calidad media sea buena.

Aclara además quién posee el código, las configuraciones y las cuentas; qué recibe otro proveedor para mantenerlo; y quién responde ante incidentes. El presupuesto operativo debe incluir modelos, infraestructura, observabilidad, revisión humana y mantenimiento, con supuestos de volumen explícitos.

Para evaluar oportunidades de IA en tu empresa, conoce mis servicios de consultoría e implementación de IA o cuéntame sobre tus procesos y necesidades. No necesitas tener una solución definida.