Un proyecto de IA puede atascarse por la calidad del modelo, por datos insuficientes, por una integración incompleta o porque el proceso no compensa. No hay una causa única que pueda diagnosticarse desde una demo. Si ya tienes un prototipo, la pregunta útil es qué falta demostrar para ponerlo en manos del equipo.
Esta guía propone una revisión antes de comprometer más desarrollo. El resultado debería ser una decisión documentada: desplegar con límites, reducir el alcance o detener el proyecto. Las comprobaciones son propuestas de trabajo; no representan resultados de un cliente ni una certificación.
Primero separa el problema del sistema elegido
Describe una tarea con entrada, salida y responsable. Por ejemplo, preparar un borrador que una persona revisa es un alcance distinto de enviar respuestas automáticamente. Compara el prototipo con el proceso actual y con una alternativa sencilla: reglas, configuración del software existente o una integración.
Si aún estás eligiendo cómo automatizar, empieza por agentes de IA frente a workflows. Aquí la decisión es posterior: comprobar si el sistema elegido está preparado para operar. Si faltan decisiones y excepciones entre equipos, revisa la memoria operativa de Company Brain antes de pedirle al modelo que reconstruya ese contexto.
Qué evidencia pedir al revisar un piloto de IA
Usaría este registro en una revisión conjunta de negocio y tecnología. Cada fila necesita una evidencia localizable, un responsable y una decisión pendiente. Una casilla marcada sin prueba no cierra el trabajo.
| Área | Evidencia que pediría | Cuándo frenar la ampliación |
|---|---|---|
| Utilidad | Comparación de la misma tarea con el proceso actual, incluida la corrección humana. | El resultado no se usa o la revisión elimina la mejora. |
| Calidad | Casos representativos, errores por tipo y versiones evaluadas. | Solo hay ejemplos elegidos para la demo o fallos graves sin resolver. |
| Datos y permisos | Fuentes autorizadas y pruebas de acceso denegado entre usuarios o clientes. | El sistema puede recuperar información fuera de su alcance. |
| Integración | Estado final verificable ante timeout, reintento y respuesta inválida. | Una ejecución incierta se presenta como completada o repite una acción. |
| Operación | Prueba de pausa, derivación manual y recuperación con un responsable. | Nadie puede detener el flujo o atender la cola de excepciones. |
| Coste | Coste total por tarea aceptada y capacidad de revisión disponible. | El presupuesto solo contempla llamadas al modelo. |
Evalúa errores por consecuencia, sin un porcentaje universal
Un acierto global puede ocultar un fallo grave en una categoría poco frecuente. Separaría los casos habituales, las entradas incompletas, las excepciones y los intentos de acceso fuera de permiso. Registraría también abstenciones, correcciones y tareas que no llegan a completarse. Un resultado correcto en una muestra pequeña no demuestra comportamiento fiable en todos los escenarios.
Acuerda los criterios antes de probar y reserva ejemplos que no se utilicen para ajustar el sistema. Compara versiones sobre esos mismos casos, y amplía el conjunto al descubrir nuevos fallos. Si un modelo puntúa a otro, contrasta sus valoraciones con revisión humana: la guía de evaluación de Google Cloud explica esa comparación. La confianza que declara el modelo no sustituye esa evidencia.
Ejemplo hipotético: un clasificador dirige solicitudes al equipo correcto, pero confunde reclamaciones urgentes con consultas generales. Antes de automatizar el reparto, mantendría esa categoría en revisión y comprobaría el retraso que introduce. La decisión puede ser automatizar solo una parte del flujo; no hace falta inventar un umbral de precisión válido para cualquier negocio.
Calcula el coste de una tarea aceptada
Separaría la inversión inicial —integración, preparación de datos y evaluación— del coste de operación. Para un periodo y volumen definidos, el coste operativo por tarea aceptada incluye modelo, herramientas, infraestructura, reintentos, revisión, corrección y mantenimiento, dividido entre las tareas que cumplen el criterio acordado. Si no hay tareas aceptadas, no hay un coste unitario útil que comparar.
Las horas de revisión deben valorarse con datos del equipo. También comprobaría qué ocurre con un pico de trabajo: un flujo que deriva muchas excepciones puede superar la capacidad disponible. La guía para comparar presupuestos ayuda a separar lo incluido, las dependencias y el mantenimiento sin atribuir un ahorro todavía no medido.
Comprueba que el equipo puede operarlo y detenerlo
Antes del despliegue, probaría una caída del proveedor, una salida inválida, un permiso revocado y una repetición del mismo trabajo. El operador debe distinguir pendiente, fallido, en revisión y completado. Guardaría identificador de ejecución, referencias de entrada, versiones, comprobaciones y estado final, con acceso y conservación definidos; no copiaría datos sensibles completos al registro por defecto.
El caso Adslyfy muestra ejecuciones y capturas de monitorización. Esa evidencia ilustra visibilidad operativa; no demuestra precisión de IA ni resultados de este checklist. Para conectar una función a un producto existente, la guía de integración de IA en un SaaS desarrolla los límites técnicos.
Decide si desplegar, acotar o detener
- Desplegar con límites: la evidencia satisface los criterios acordados para un alcance concreto, hay responsable y se ha probado cómo volver al proceso anterior.
- Acotar: solo una categoría o un equipo cumple los criterios. Mantén el resto fuera del despliegue y define qué prueba permitiría ampliarlo.
- Detener o replantear: no hay utilidad frente a la alternativa, faltan datos necesarios o quedan fallos que impiden operar dentro de los límites acordados.
Dejaría por escrito alcance autorizado, evidencia, limitaciones, responsable y motivo para revisar la decisión. Repetiría la evaluación al cambiar modelo, prompt, fuentes o herramientas; una revisión inicial no garantiza el comportamiento futuro.
Qué encargar para desbloquear el proyecto
Si falta decidir qué corregir primero, puedo revisar el sistema y priorizar el trabajo desde CTO externo y dirección técnica. Si el alcance ya está claro, el servicio de automatización e IA aplicada cubre la construcción del flujo y sus controles.
Para preparar esa conversación, reúne el proceso actual, una demo, ejemplos permitidos de aciertos y fallos, sistemas conectados y quién operará el resultado. Cuéntame dónde se ha atascado tu piloto y podremos definir qué necesita demostrar el siguiente tramo de trabajo.