Cómo evaluar un proyecto de IA: cinco preguntas antes de aprobar
DominicodeUn responsable de operaciones entra en la reunión con la frase ya montada: "queremos un agente para las devoluciones".
Primera pregunta del árbol. ¿Los pasos son siempre los mismos, y en el mismo orden?
Sí. Salvo cuando el importe supera cierto umbral.
Fin del árbol. En la pregunta uno.
Lo que necesitaba era un workflow con una excepción. Y estaba presupuestando diez veces eso.
Esto es lo que no sale en la diapositiva de nadie que venga a venderte algo, y es el fondo de cómo evaluar un proyecto de IA: el resultado más frecuente de hacerlo bien es descubrir que no hacía falta un agente. No es falta de ambición. Es lo que hace que el proyecto siga vivo dentro de dos años.
Y hay un motivo egoísta para que te importe aunque tú no firmes ningún presupuesto: la decisión mala la acabas implementando tú.
Si lo que buscas es el vocabulario —qué es un agente y qué no—, está entero en esta guía. Aquí no definimos nada. Aquí decidimos, y le ponemos precio a cada decisión.
Resumen rápido
- Cinco preguntas, en orden, y se para en la primera que aplique. No es un cuestionario: es un árbol.
- Cada peldaño que subes multiplica el coste. La gracia está en pararse en el más bajo que resuelve el problema.
- En IA el éxito es lo que dispara el coste: se paga por uso, así que si la herramienta gusta, la factura sube con ella.
Cómo evaluar un proyecto de IA: el árbol de cinco preguntas
Evaluar un proyecto de IA es recorrer estas cinco preguntas en orden y parar en la primera que aplique:
- ¿Los pasos son siempre los mismos, y en el mismo orden? Si sí, es un workflow, no un agente.
- ¿Basta con leer y escribir texto, sin tocar ningún otro sistema? Si sí, basta un chat con buen contexto.
- ¿Hay que decidir sobre la marcha según lo que se encuentre? Si no, workflow otra vez.
- Si se equivoca, ¿se puede deshacer? Si no, agente con una persona aprobando cada acción con consecuencias.
- ¿Puedes medir si lo ha hecho bien? Si no, todavía no va a producción.
Cada peldaño que superas multiplica el coste, así que evaluar bien un proyecto de IA consiste en pararse en el escalón más bajo que resuelve el problema.
La decisión se toma casi siempre al revés. Alguien quiere hacer algo con IA y después busca dónde encajarlo. Así es como acabas pagando la flexibilidad de un agente para ejecutar cinco pasos que nunca cambian.
El árbol invierte el orden. Primero el problema, después la herramienta. Y así es como se ve cuando lo pones en una hoja, que es la forma en que de verdad se usa en una reunión:
1. ¿Los pasos son siempre los mismos,
y en el mismo orden?
└─ SÍ → workflow. No agente.
↓ NO
2. ¿Basta con leer y escribir texto,
sin tocar ningún otro sistema?
└─ SÍ → un chat con buen contexto.
↓ NO
3. ¿Hay que decidir sobre la marcha
según lo que se encuentre?
└─ NO → workflow otra vez.
↓ SÍ
4. Si se equivoca, ¿se puede deshacer?
└─ NO → agente, pero con una
persona aprobando todo
lo que tenga consecuencias.
↓ SÍ
5. ¿Puedes medir si lo ha hecho bien?
└─ NO → todavía no va a producción.
↓ SÍ
→ Adelante. Empieza con los permisos
mínimos y ábrelos según se los gane.
Ninguna de las cinco es técnica: se contestan describiendo el proceso. Vamos una a una, con el precio de quedarse en cada peldaño al lado. Porque el árbol no va de arquitectura. Va de dinero.
Uno. ¿Los pasos son siempre los mismos y en el mismo orden?
Si la respuesta es sí, ya has terminado. No necesitas un agente: necesitas un workflow.
Más barato, más rápido, auditable, y no improvisa. Cuando falla, el informe de incidencia cabe en una línea: falló el paso tres. Eso también es dinero, porque nadie factura horas reconstruyendo qué pasó.
Esta pregunta se salta por una razón muy humana: describir un proceso como "variable" suena mejor que describirlo como "cinco pasos y una excepción". Pero el caso de las devoluciones es el típico, no la anomalía. Los pasos son fijos salvo un caso, y ese salvo se convierte en el argumento para presupuestar un sistema entero.
Un if no es variedad. Es un if.
Y aquí está el multiplicador que hace que esta pregunta valga tanto dinero: un agente que da quince vueltas en lugar de tres no cuesta cinco veces más. Cuesta bastante más, porque el coste no crece con el número de vueltas, sino con la suma de todas las anteriores: cada una reenvía el contexto completo. Un workflow ejecuta los pasos que escribiste y para.
Muchos candidatos a agente son procesos que pueden escribirse tal cual, y los desmenucé en cómo automatizar tu proceso de desarrollo con IA.
Lo que pagas aquí: ingeniería una vez, ejecución predecible. Es el único escalón donde la factura no depende de que la herramienta guste.
Dos. ¿Basta con leer y escribir texto, sin tocar ningún otro sistema?
Si es que sí, te sobra con un chat con buen contexto. Súmale tus documentos y ya está.
Redactar, resumir, reformular, clasificar. Nada de eso toca un sistema ni necesita permisos, y montarlo es cuestión de días.
Lo que se subestima aquí no es la capacidad. Es la latencia.
Un asistente que tarda ocho segundos sirve perfectamente para redactar un informe. El mismo asistente delante de un cliente al teléfono es inaceptable. La calidad es idéntica; el uso, imposible. Y un agente multiplica esa espera por el número de vueltas: lo que en un chat son ocho segundos, en un agente pueden ser dos minutos.
Regla que uso siempre: si hay una persona esperando, la latencia es un requisito, no un detalle. Si el proceso corre de madrugada, da igual lo que tarde.
Lo que pagas aquí: sube con el número de personas, no con la complejidad. Es el escalón que menos sorpresas da.
Tres. ¿Hay que decidir sobre la marcha según lo que se encuentre?
Si es que no, workflow otra vez.
Esta pregunta existe porque hay procesos que tocan varios sistemas —por eso pasaron la dos— pero donde el orden sigue estando escrito de antemano. Leer un correo, extraer datos, meterlos en el CRM, avisar por Slack. Toca cuatro cosas. No decide ninguna.
El error de asignación es carísimo y se repite: mover datos de un sitio a otro no necesita un modelo eligiendo el siguiente paso. Necesita una automatización de las de siempre, con IA solo en el hueco donde hace falta criterio.
El árbol decide un proyecto entero. Cuando lo que tienes delante es un backlog y no un presupuesto, la unidad cambia: se decide tarea por tarea, y eso está en cómo clasificar tareas de desarrollo para delegarlas a la IA.
Lo que pagas aquí: lo mismo que en la uno, más las ramas que hay que mantener. Sigue siendo el barato.
Cuatro. Si se equivoca, ¿se puede deshacer?
Si la respuesta es no, la respuesta tampoco es "no lo hagas". Es: agente sí, pero con una persona aprobando cada acción con consecuencias.
Sin excepciones. Y sin renegociarlo a la baja tres semanas después porque aprobar es un incordio.
Pagar, contratar, publicar, borrar, escribir a clientes reales, migrar datos de producción. Ninguna de esas se deshace con un ctrl+Z, y todas tienen un coste que ya no es de infraestructura: es de reputación, de contrato o de nómina.
La parte que no aparece en ninguna hoja de cálculo: esa persona es un coste recurrente y no escala. Revisar el diez por ciento de las salidas es viable con cien casos al día e imposible con diez mil. El proveedor absorbe el volumen sin despeinarse. Quien lo vigila, no.
Y si el proyecto solo sale a cuenta cuando quitas al humano de en medio, entonces no sale a cuenta. Eso es información valiosa, y llega gratis si haces la pregunta antes de firmar.
Lo que pagas aquí: el modelo por las vueltas, más el tiempo de quien aprueba. Este es el peldaño donde el presupuesto cambia de orden de magnitud, no de porcentaje.
Cinco. ¿Puedes medir si lo ha hecho bien?
Si es que no, no lo pongas en producción todavía.
No porque vaya a salir mal desde el primer día. Al revés: va a salir bien, porque los pilotos salen bien.
El problema llega después. Sin forma de medir no vas a saber si empeora, y va a empeorar: cambias de modelo, cambia el tipo de casos que llegan, alguien toca un prompt. Todo eso ocurre sin que salte ninguna alarma, porque no hay alarma.
Medir son dos cosas y hacen falta las dos. Una señal automática que diga si la ejecución fue correcta. Y la traza de qué decidió el sistema y con qué información, que es lo que te deja reconstruir un incidente en vez de opinar sobre él — la lista de qué guardar de cada ejecución la tienes en este repaso de observabilidad para agentes.
Decidir qué salida es aceptable antes de construir, en lugar de parchearlo cuando ya ha explotado, es el trabajo que describo en el libro de Spec-Driven Development. No es burocracia: es lo que hace que la pregunta cinco tenga respuesta el día que la haces.
Lo que pagas aquí: todo lo anterior más la infraestructura de medir. Y esa no se va nunca, porque es la que sostiene el resto.
Si llegas al final del árbol, adelante. Un agente es la respuesta correcta y merece la pena. Empieza con los permisos mínimos y ábrelos según se los gane.
Dónde te paras y qué pagas
Cada parada del árbol tiene un perfil de coste distinto, y esa es la información que falta en casi todos los presupuestos:
| Dónde se para el árbol | Lo que pagas de verdad |
|---|---|
| Pregunta 1 → workflow | Ingeniería una vez. Ejecución predecible |
| Pregunta 2 → chat con contexto | Por conversación. Sube con las personas |
| Pregunta 3 → workflow otra vez | Igual que 1, más ramas que mantener |
| Pregunta 4 → agente con aprobación | Modelo × vueltas + tiempo de quien aprueba |
| Pregunta 5 → agente instrumentado | Todo lo anterior + medir, para siempre |
Esta tabla es la razón de que el orden de las preguntas no sea decorativo.
Anthropic lo dice sin rodeos en Building effective agents (diciembre de 2024): la recomendación es buscar siempre la solución más simple posible, y eso "puede significar no construir sistemas agénticos en absoluto". Es la empresa que te cobra por vuelta diciéndote que des menos vueltas.
Cuánto cuesta un proyecto de IA: la cuenta que casi nadie hace
Un proyecto de IA no se paga por licencia: se paga por uso. Un taxímetro, no un abono.
En el software al que estás acostumbrado, el usuario número mil sale casi gratis. Aquí no: cada respuesta rehace un cálculo entero, y ese cálculo cuesta dinero.
De ahí sale la frase que te va a servir en cualquier reunión de presupuesto: en IA, el éxito es lo que dispara el coste. Si la herramienta gusta y la usa todo el mundo, la factura sube en la misma proporción. Al revés de lo que espera un director financiero.
Así que la cuenta es esta, y se hace antes: coste por consulta × número de consultas al mes, con el escenario de que la herramienta guste.
Un piloto de diez personas y una implantación de dos mil no se diferencian en dos veces. Se diferencian en dos órdenes de magnitud. Y dos detalles estropean cualquier estimación hecha a ojo: lo que sale se cobra varias veces más caro que lo que entra —está en las tarifas públicas de Anthropic y en las de cualquier otro proveedor—, y una conversación larga cuesta más que la suma de sus mensajes, porque cada turno reenvía todo lo anterior.
Esa asimetría entre lo que entra y lo que sale, con los números de coste al lado, la desglosé en IA generativa vs IA agéntica.
El piloto es el diez por ciento del trabajo aunque parezca el noventa
Un piloto se monta en semanas y sale bien: casos elegidos, gente motivada y alguien vigilando de cerca.
Producción es otra cosa. Aparecen los casos raros, los usos que nadie previó, el mantenimiento de la base de conocimiento y la factura de verdad. Y aparece el punto que más proyectos entierra: quién se ocupa de esto dentro de un año. El piloto lo llevó alguien con ilusión en un rato libre. Producción necesita un dueño en el organigrama.
| Piloto | Producción | |
|---|---|---|
| Casos | Elegidos a mano | Los que lleguen, incluidos los raros |
| Usuarios | Motivados y avisados | Todos, y sin leer las instrucciones |
| Supervisión | Alguien mirando de cerca | Una revisión semanal que hay que asignar |
| Coste | Casi ruido | Coste por consulta × volumen real |
| Dueño | Quien tuvo la idea | Una persona en el organigrama |
La regla, dura a propósito: si al terminar el piloto no sabes decir quién lo mantiene, cuánto costará al volumen real y quién lo revisa cada semana, el piloto no ha terminado. Ha terminado la parte divertida.
Cómo evaluar un proyecto de IA cuando no hay un "antes" que medir
Empieza por procesos donde puedas medir el antes. Es la regla que evita la mayoría de los disgustos, y se entiende sola: si no sabes cuánto tardabais en tramitar una devolución antes de la IA, tampoco vas a poder demostrar que ahora tardáis menos. Y sin eso, la renovación del presupuesto se decide por sensaciones.
Cuidado con lo que eliges medir, porque lo que midas es lo que vas a conseguir. Si mides volumen tendrás volumen: más documentos generados, más tickets cerrados y ninguna certeza de que algo haya mejorado. Qué métricas dicen la verdad lo desarrollé en cómo medir la productividad de equipos que usan IA.
Por qué te importa aunque tú no firmes nada
Este árbol es cosa de quien firma. Por eso te importa a ti.
Cuando alguien aprueba un agente para un proceso de cinco pasos fijos, tú eres quien pasa los seis meses siguientes intentando que un sistema no determinista se comporte de forma determinista. Vas a montar guardrails para forzar un orden que cabía en un switch. Vas a depurar ejecuciones que no se repiten. Vas a explicar por qué sube la factura.
Todo eso era evitable en la pregunta uno, en una reunión de veinte minutos a la que probablemente no te invitaron.
La jugada es sencilla: haz tú las cinco preguntas, en voz alta, antes de que se decida nada. No hace falta ser quien firma para ser quien pregunta.
Y cuando la decisión ya está tomada y lo que te llega es una frase de reunión, el trabajo es traducirla antes de que se convierta en alcance: cómo explicar IA a tu jefe y las seis frases que acaban en tu sprint.
Y si quieres contrastar el árbol antes de usarlo, esa conversación pasa cada semana en Dominicode Labs, con gente que ya tiene estos sistemas corriendo.
Y si quieres el recorrido de idea a producto con este criterio aplicado desde el primer día, es el camino del curso Construye con IA.
Lo único que tienes que hacer hoy
Coge el proyecto de IA que ya está aprobado. Ese, no el que viene.
Y contesta la pregunta uno: ¿los pasos son siempre los mismos y en el mismo orden?
Si la respuesta empieza por "sí, salvo cuando…", ese salvo es la conversación que tienes que provocar esta semana. Porque casi siempre es un if, y estás pagando por un sistema que decide para no tener que escribirlo.
El árbol sale de un libro que estoy terminando, El mapa de la inteligencia artificial: 120 conceptos para gente que decide sin escribir código. Mientras tanto, esos conceptos colocados por zonas —y estas cinco preguntas en formato imprimible— los tienes gratis en el mapa desplegable.
Imprímelo y déjalo en la sala de reuniones. Mejor aún: pásaselo a quien te aprueba el presupuesto. Ahí es donde de verdad hace su trabajo.
Preguntas frecuentes
¿Cómo se evalúa si un proyecto de IA merece la pena?
Con un árbol de cinco preguntas que se recorre en orden y se detiene en la primera que aplique: si los pasos son siempre los mismos, si basta con leer y escribir texto, si hay que decidir sobre la marcha, si el error es reversible y si puedes medir el resultado. Cada peldaño que subes multiplica el coste y el riesgo, así que evaluar bien es pararse en el escalón más bajo que resuelve el problema.
¿Cuándo compensa pagar por un agente y cuándo basta con un workflow?
Un agente solo justifica su precio cuando el camino cambia según lo que el sistema encuentra durante la ejecución, y pagar flexibilidad para un proceso fijo es el error más caro de esta lista. Si los pasos están fijados de antemano, un workflow es más barato, más rápido y auditable. Si el trabajo se agota en leer y escribir texto sin tocar otros sistemas, un chat con buen contexto y tus documentos resuelve el caso en días.
¿Por qué la primera pregunta ahorra tanto dinero?
Porque corta los proyectos más caros antes de que existan. Un agente que da quince vueltas en lugar de tres multiplica la factura, y cada vuelta reenvía todo el contexto anterior, así que el coste no crece con el número de pasos sino con la suma de todos los anteriores. Cuando el proceso es fijo salvo una excepción, pagas por una decisión que se toma miles de veces y siempre sale igual.
¿Cuánto cuesta realmente un proyecto de IA?
No se paga por licencia, se paga por uso: la cuenta correcta es coste por consulta multiplicado por consultas al mes, calculada con el escenario de que la herramienta guste. Un piloto de diez personas y una implantación de dos mil se separan en dos órdenes de magnitud, no en dos veces. Súmale lo que casi nunca se presupuesta: quien revisa, el mantenimiento de la base de conocimiento y el dueño del sistema.
¿Por qué un piloto que funciona no garantiza que el proyecto funcione?
Porque el piloto se hace con casos elegidos, gente motivada y alguien vigilando de cerca. En producción aparecen los casos raros, los usos que nadie previó, los límites de las APIs y la supervisión semanal. Lo que no escala no es la infraestructura, que el proveedor absorbe sin inmutarse: es la parte humana de revisar, mantener y decidir.
¿Qué hago si no puedo medir si el sistema lo hace bien?
No lo pones en producción todavía. Sin una señal que diga si una ejecución fue correcta no vas a enterarte de que el sistema empeora, y va a empeorar en cuanto cambie el modelo, cambien los casos o alguien toque un prompt. Antes de subirlo necesitas dos cosas: una comprobación automática del resultado y la traza de qué decidió el sistema con qué información.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.