Cinco preguntas que aplico antes de proponer cualquier implementación. Si fallas dos, no toca todavía.
La mayoría de los proyectos de IA que he visto atascarse no se atascaron por el modelo. El problema venía de antes: nadie había definido bien qué trabajo se quería mejorar, los datos no estaban tan disponibles como parecía o la solución dependía de que una persona revisara manualmente todo lo que hacía el sistema.
En muchas conversaciones se empieza hablando de herramientas, proveedores o modelos. Yo intento empezar un poco antes.
Antes de proponer una implementación, paso el caso de uso por estas cinco preguntas. No es una metodología científica: es un filtro práctico para detectar cuándo una idea está preparada para probarse y cuándo necesita trabajo previo.
Mi regla es esta: si dos de las cinco respuestas no están claras, todavía no construiría.
Ese "todavía" es importante. No significa que la idea sea mala: significa que antes hay que resolver algo.
En una reunión suelo pedir algo muy sencillo:
Cuéntame qué ocurre hoy, quién lo sufre y cómo sabes que es un problema.
Las respuestas útiles se parecen a estas:
No hace falta tener calculado el retorno de la inversión hasta el último euro. Pero sí tiene que existir un problema observable.
"Queremos aplicar IA" no describe un problema. "Queremos un asistente interno" tampoco. Las dos frases describen una posible solución.
A veces, al quitar las palabras IA, agente o copiloto, la propuesta se queda vacía. No pasa nada. Es mejor descubrirlo en una conversación de una hora que después de tres meses de piloto.
El miedo a quedarse atrás puede abrir la conversación, pero no debería aprobar una inversión. Primero hay que entender el trabajo. Después elegimos la herramienta.
Cuando alguien me dice "tenemos todos los datos", la siguiente pregunta no es cuántos terabytes ocupan. La pregunta es: ¿podemos abrir ahora mismo una muestra representativa?
Unos cuantos documentos reales suelen contar más que una diapositiva que dice "disponemos de histórico". Aquí compruebo tres cosas.
Puede haber años de actividad y muy poco conocimiento registrado: incidencias que se resuelven por teléfono, excepciones que se conocen de memoria, decisiones repartidas entre correos y personas con experiencia.
La empresa tiene conocimiento, pero todavía no tiene un conjunto de datos que un sistema pueda consultar o utilizar.
Que un documento exista no significa que sea utilizable. Puede estar en un ERP sin una forma razonable de extraerlo, en PDFs escaneados, en carpetas personales o en quince hojas de cálculo con estructuras diferentes.
Si es así, hay un trabajo previo de recopilación, limpieza, permisos o integración. No aparecerá resuelto por el camino: conviene identificarlo, presupuestarlo y asignarle un responsable.
Quién puede acceder a la información, qué datos personales o confidenciales contiene y en qué entorno puede procesarse. Que técnicamente podamos conectar una carpeta a un modelo no significa que debamos hacerlo, ni en cualquier condición.
Cuando alguna de estas capas falla, separo el trabajo en dos fases: primero preparar las fuentes, después evaluar la solución de IA. Intentar ambas a la vez suele ocultar costes y alargar el proyecto.
No pregunto solamente qué porcentaje de acierto esperamos. Pregunto cuatro cosas:
No cuesta lo mismo corregir un resumen interno que una oferta enviada a un cliente. Un borrador de correo se revisa en segundos; un precio incorrecto o una instrucción técnica inventada tienen consecuencias mucho mayores.
El coste del error determina el diseño. Cuando el error es limitado y reversible, puede haber bastante autonomía. Cuando es caro, difícil de detectar o afecta a terceros, hace falta control antes de ejecutar la acción.
Pero añadir "una persona validará el resultado" no resuelve nada por sí solo. ¿Tiene esa persona el contexto necesario? ¿Cuántas revisiones puede asumir? Si recibe doscientas respuestas al día y acaba pulsando "aceptar" por inercia, la validación humana existe en el diagrama, pero no en la práctica.
La revisión también se diseña: mostrar el documento original, destacar qué información ha usado el sistema, dar una vía clara para corregir y escalar. Ese tiempo forma parte del coste real. Si revisar cuesta casi lo mismo que hacer el trabajo desde cero, el caso de negocio cambia bastante.
Esta es una de las preguntas más importantes y, a veces, la más incómoda.
Hay problemas que llegan formulados como casos de uso de IA y se resuelven mejor con un campo obligatorio, una plantilla, una regla de validación, un buscador decente o una automatización clásica.
La pregunta no es si un modelo puede hacer la tarea (probablemente pueda hacer alguna parte). Es si la IA es la forma más fiable y razonable de conseguir el resultado.
La IA suele aportar valor cuando existe variabilidad real: lenguaje natural, documentos con estructuras diferentes, información dispersa o situaciones que requieren interpretar contexto. Cuando la tarea siempre sigue las mismas reglas, una solución determinista suele ser más barata, más fácil de explicar y más sencilla de mantener.
Antes de añadir un modelo, imagino qué parte del problema seguiría resolviéndose si mañana desapareciera la IA de la propuesta. A veces la respuesta es "casi todo". En esos casos, lo responsable es construir primero la solución sencilla y evaluar después si la IA aporta algo a la parte variable.
Usar IA donde una regla fija funciona mejor no hace que el proyecto sea más avanzado. Solo añade complejidad.
Un sistema de IA no queda terminado el día que entra en producción. Cambian los documentos, los procesos, los usuarios, los proveedores y los costes. Lo que funcionaba con la primera muestra puede dejar de funcionar con el uso diario.
Por eso, antes de construir, necesito saber quién asumirá estas responsabilidades dentro de la organización:
En una organización pequeña, varias de estas funciones pueden recaer en la misma persona. Lo importante es que existan y que no se descubran después del lanzamiento.
El consultor externo puede acompañar, resolver dudas o encargarse de parte del mantenimiento. Lo que no debería ser es la única persona que sabe qué fuentes utiliza el sistema, dónde están las credenciales o qué hacer cuando algo falla. Si todo depende de llamar al proveedor, no se ha creado una capacidad interna. Se ha creado una dependencia.
Parte de mi trabajo consiste precisamente en dejar documentación, criterios de evaluación y personas preparadas para que el sistema pueda seguir funcionando sin mí.
Estas cinco preguntas no producen únicamente un "sí" o un "no". Producen un diagnóstico.
A veces el caso está preparado para una prueba: el problema es concreto, hay datos utilizables, el error está acotado, no existe una alternativa más sencilla y alguien asumirá la responsabilidad.
Otras veces la idea es buena, pero antes hay que ordenar documentos, registrar mejor las incidencias o decidir quién será el propietario del sistema.
Y en algunos casos la respuesta correcta es que no hace falta IA. Hace falta una automatización de toda la vida, una plantilla mejor o una decisión organizativa que se llevaba demasiado tiempo posponiendo.
El umbral de dos fallos no tiene ninguna pretensión matemática. Me ayuda a evitar que el entusiasmo por la tecnología tape dos carencias importantes al mismo tiempo. Un fallo puede asumirse dentro de un piloto bien acotado; dos suelen indicar que todavía estamos construyendo sobre una base que no está preparada.
Los proyectos que llegan a producción no son necesariamente los que empiezan con la demostración más espectacular. Son aquellos en los que alguien puede explicar, con bastante claridad, qué problema se está resolviendo, qué información se utiliza, qué errores son aceptables y quién se hará cargo del sistema el lunes siguiente.
Si quieres pasar un proceso concreto por esta lógica en forma de diagnóstico guiado, para eso está Depende: doce preguntas y una recomendación honesta — incluida la de no usar IA todavía.