Cada trimestre recibo mensajes de directores de operaciones y directores financieros con una queja recurrente: han destinado entre 30.000 y 80.000 euros a una iniciativa de inteligencia artificial, llevan seis meses de desarrollo y el sistema sigue sin poder pasar a producción. En el mejor de los casos tienen una demo vistosa que impresiona al comité de dirección; en el peor, una integración frágil que alucina con datos de clientes y genera costes impredecibles por consumo de API.
Mi experiencia auditando iniciativas tecnológicas en startups del ecosistema de Lanzadera y en medianas empresas industriales me ha demostrado un patrón claro: los proyectos de software tradicional fallan por mala gestión de expectativas o alcances mal definidos, pero los proyectos de inteligencia artificial suelen fracasar por inviabilidad técnica intrínseca que nadie se molestó en medir antes de firmar la orden de compra.
En GHEN Digital aplico un marco estricto de diagnóstico previo antes de que cualquiera de mis clientes asigne un solo euro a desarrollo. En este texto detallo los pilares de esa evaluación previa, los puntos de fricción que destruyen la rentabilidad de estas iniciativas y el método exacto con el que determino si una idea merece presupuesto o debe descartarse de inmediato.
Por qué fracasa la mayoría de iniciativas de inteligencia artificial aplicada
El error de partida suele ser el mismo: confundir la capacidad general de un modelo fundacional con la viabilidad operativa de integrarlo en un proceso de negocio específico. Cuando un proveedor externo o un equipo interno presenta una propuesta basada únicamente en llamadas a APIs comerciales, rara vez calcula la degradación del rendimiento cuando el volumen escala o cuando los datos de entrada se desvían de los ejemplos ideales.
He visto empresas presupuestar desarrollos complejos asumiendo una precisión del 95% basada en pruebas con veinte documentos seleccionados a mano. Al conectar la solución a un repositorio documental real de 10.000 contratos escaneados con baja resolución, tipografías heterogéneas y firmas superpuestas, la precisión cayó por debajo del 60%. En ese punto, el coste humano de revisar cada salida del modelo superaba con creces el coste de mantener el proceso manual previo.
Una auditoria proyectos ia rigurosa no evalúa si la tecnología existe en el mercado, sino si los requisitos del caso de uso concreto son compatibles con las limitaciones matemáticas y económicas de los modelos disponibles. Si el éxito de tu caso de uso depende de una tasa de error cero en tareas no estructuradas, la inteligencia artificial generativa no es la solución adecuada, al menos no de forma aislada.
Las cuatro capas de mi diagnóstico de viabilidad previa
Cuando evalúo una iniciativa corporativa antes de su fase de implementación, divido el análisis en cuatro capas secuenciales. Si un proyecto no supera una de ellas de forma cuantitativa, se detiene la evaluación:
1. Calidad, volumen y accesibilidad de los datos
Sin datos procesables no hay sistema predictivo ni generativo que funcione. No hablo únicamente de tener bases de datos accesibles, sino de analizar la variabilidad del esquema y la veracidad de la información histórica. Si tus registros tienen campos incompletos, inconsistencias de etiquetado o formatos no normalizados, el 70% del presupuesto se consumirá en tareas de saneamiento de datos antes de poder tocar un modelo. En mi auditoría inicial exijo una muestra estadística representativa de al menos 500 registros reales para medir entropía, valores nulos y ruido antes de emitir una valoración.
2. Tolerancia operativa al error y consecuencias del fallo
Todo sistema probabilístico comete fallos. Mi trabajo consiste en cuantificar qué ocurre cuando el modelo falla:
- Si el fallo supone una recomendación de producto irrelevante en un ecommerce, la tolerancia es alta y el proyecto suele ser viable.
- Si el fallo implica emitir una factura incorrecta, validar una cláusula legal inválida o enviar una respuesta médica errónea, la tolerancia al fallo es prácticamente nula.
Cuando la tolerancia al error es baja, audito la arquitectura de validación determinista. Si el coste de supervisión humana (human-in-the-loop) para mitigar el riesgo anula el ahorro operativo del sistema, el proyecto carece de sentido financiero.
3. Economía unitaria y latencia máxima admisible
Muchos presupuestos omiten el coste recurrente de inferencia. En GHEN Digital calculo el coste por transacción modelando tres escenarios: volumen base, picos estacionales y casos extremos de tokens de entrada. Si procesar una consulta cuesta 0,08 euros y el margen de contribución del producto es de 0,15 euros, la viabilidad financiera está comprometida ante cualquier variación de uso. Igualmente, si el flujo de trabajo del usuario exige respuestas en menos de 800 milisegundos, una cadena compleja de prompts que tarde cuatro segundos destruirá la tasa de adopción interna.
4. Gobernanza, privacidad y dependencia de terceros
Analizo dónde residen los datos y qué normativas aplican (RGPD, AI Act europeo o regulaciones sectoriales). Depender enteramente de APIs propietarias de terceros introduce riesgos de disponibilidad, cambios arbitrarios de políticas de uso y modificaciones silenciosas en el comportamiento de los modelos que pueden romper flujos operativos de la noche a la mañana.
Especificación antes de código: La barrera contra el desvío presupuestario
El mayor destructor de caja en las empresas que asesoro es el desarrollo exploratorio sin límites definidos. Se contrata a un equipo para “probar qué se puede hacer con IA”, y tres meses después solo existen cuadernos de Jupyter Notebook sin salida a producción.
Para evitar esto, aplico con rigor el enfoque de Desarrollo Dirigido por Especificaciones. Antes de escribir una sola línea de código o levantar un contenedor en la nube, documento:
- El contrato exacto de entrada y salida (por ejemplo, esquemas JSON estrictos con validación de tipos).
- El conjunto de pruebas de referencia (eval dataset) compuesto por casos límite reales que el sistema debe superar con un porcentaje de acierto predeterminado.
- El protocolo de contingencia automática (fallback) cuando el modelo devuelva una salida fuera de especificación o supere el umbral de latencia.
Al establecer estas reglas desde el primer día, transformo una iniciativa abstracta en un entregable medible contra criterios de aceptación objetivos. Si una solución no puede cumplir la especificación acordada en un prototipo acotado de dos semanas, cancelamos la línea de desarrollo antes de comprometer el presupuesto mayor.
Cuándo usar agentes y cuándo limitarse a flujos deterministas
Existe una tendencia peligrosa a sobrediseñar soluciones. He auditado arquitecturas empresariales donde habían implementado grafos multi-agente con cinco roles distintos para resolver tareas que se solucionaban con un script en Python bien estructurado y una llamada a base de datos relacional.
Cada agente adicional en un sistema introduce latencia acumulada, coste multiplicativo de inferencia y una superficie exponencial de puntos de fallo. En mi análisis técnico sobre el BMAD Method vs Workflow de Agentes IA explico cómo la coordinación descontrolada de agentes suele generar más problemas de coherencia operativa que soluciones reales.
Mi criterio de auditoría es pragmático:
* Usa lógica determinista (código tradicional, APIs REST, reglas de negocio) para el 90% del flujo: enrutamiento, validación de permisos, cálculo numérico y persistencia.
* Reserva los modelos probabilísticos exclusivamente para tareas donde exista ambigüedad real en el lenguaje natural o extracción semántica compleja.
* Si un proveedor te propone una arquitectura puramente agéntica para procesos internos con reglas de negocio fijas, desconfía de la propuesta.
El checklist de control previo para comités de dirección
Antes de aprobar cualquier partida presupuestaria vinculada a inteligencia artificial, someto la propuesta a estas cinco preguntas de control con métricas cerradas:
| Pregunta de Control | Criterio de Aprobación Mínimo | Riesgo Asociado si se Ignora |
|---|---|---|
| ¿Existe un dataset de evaluación curado? | Mínimo 200 casos de prueba reales con resultado esperado validado por expertos de negocio. | Incapacidad de medir si las mejoras en prompts degradan otras respuestas (regresión silenciosa). |
| ¿Cuál es el coste por transacción estimado? | Proyección con desglose de tokens/computación que no supere el 20% del margen del proceso. | Ruptura de la rentabilidad unitaria al escalar el volumen de usuarios. |
| ¿Cuál es el tiempo de respuesta tolerable? | SLA definido por contrato de interfaz (ej. P95 < 1.500 ms). | Abandono de uso por parte de los empleados o clientes debido a lentitud. |
| ¿Existe un mecanismo determinista de fallback? | Redirección automática a operador o respuesta segura si el modelo falla. | Exposición a alucinaciones graves o fugas de información sensible. |
| ¿Quién asume el mantenimiento de prompts/modelos? | Asignación explícita de horas internas o externas para supervisar drift semántico. | Obsolescencia del sistema a los tres meses de su puesta en marcha. |
Si el equipo promotor del proyecto no puede responder a tres de estas cinco preguntas con datos verificables, mi recomendación siempre es la misma: congelar la inversión en desarrollo y financiar únicamente un estudio de viabilidad técnica acotado en tiempo y coste.
