¿Qué cuenta como IA? Una definición útil para la ingeniería en 2026
La definición de manual de la IA — «sistemas que realizan tareas que normalmente requieren inteligencia humana» — ya acusaba la edad hace una década. En 2026 es directamente un estorbo. Casi cualquier software moderno realiza tareas que «normalmente requieren inteligencia humana». Una tabla dinámica de una hoja de cálculo normalmente requiere inteligencia humana. Una consulta SQL normalmente requiere inteligencia humana. Llamarlas IA es un error de categoría; fingir que no lo son, también.
Los ingenieros necesitamos una definición que guíe decisiones, no notas de prensa. La propuesta que Georgios Fradelos plantea en Updated Definition of Artificial Intelligence (diciembre de 2025) es el encuadre más útil para ingeniería que he visto en bastante tiempo. Merece la pena desgranarla, porque adoptarla cambia cómo acotas proyectos, cómo evalúas proveedores y cómo presupuestas infraestructura.
La definición es una prueba que puedes ejecutar
Sin las referencias, queda así:
Cualquier pieza de software que analiza y/o genera datos (incluso para su propio entrenamiento) y puede producir de forma rutinaria, con intervención humana solo excepcional:
- Mejores resultados en tareas de análisis y/o síntesis que el profesional humano medio de hoy, dentro de la misma cultura profesional, con independencia del coste energético; o
- Resultados comparables en tareas de análisis y/o síntesis, obtenidos más rápido y/o con un coste energético mediblemente menor; o
- Ambos.
Tres rasgos hacen que esta definición sea útil para tomar decisiones de ingeniería.
Se ata al resultado, no a la arquitectura. Le da igual que el sistema use redes neuronales, IA simbólica, búsqueda o reglas escritas a mano. Si el sistema desplegado supera de forma rutinaria una línea base profesional (en calidad, velocidad o energía), cuenta. Si no la supera, no cuenta, lleve lo que lleve por dentro. Esto entierra el debate de «¿la técnica X es de verdad IA?» y lo sustituye por una prueba medible.
Tiene la energía en cuenta. El coste energético es una dimensión de primer orden de la definición, no una externalidad. Un sistema que produce resultados «comparables» a los de un profesional humano pero gasta 100× más energía en conseguirlos no es una mejora: es una degradación con pasos de más. Esto obliga a ser honestos sobre si el despliegue de IA es de verdad una mejora neta o una subida de costes a la moda.
Está acotada por la cultura profesional. La línea base de referencia es «el profesional humano medio de hoy, dentro de la misma cultura profesional». No el humano mediano. No una línea base de los noventa. No una meta aspiracional. Eso ancla la comparación en algo medible y vigente, y obliga a reevaluar a medida que la línea base se mueve.
Por qué esto le sirve a un CTO
Tres decisiones concretas se vuelven más fáciles con este encuadre.
Evaluación de proveedores
Cuando un proveedor dice que su producto «lleva IA», la pregunta se vuelve concreta: ¿a qué línea base profesional supera, por cuánto y a qué coste energético? Si el proveedor no sabe responder, no tienes una afirmación de IA: tienes una afirmación de marketing.
En la práctica, esta conversación destapa mucho. Una fracción nada despreciable de las herramientas «de IA» que he evaluado en 2026 entrega una calidad comparable a la de un profesional júnior con un coste de infraestructura superior al de un profesional júnior. Eso no es un despliegue de IA; es un experimento de IA. Los dos son legítimos, pero se presupuestan de forma distinta.
Acotación de proyectos
La definición te da un criterio de puesta en producción. El sistema está listo cuando produce de forma rutinaria resultados (a) mejores, (b) más rápidos o (c) más baratos por unidad que la línea base humana a la que sustituye o complementa. No «la demo impresiona». No «a dirección le gustan las capturas». Rutinario, medible, anclado a una línea base.
Este es el umbral que la mayoría de los pilotos de GenAI que he visto incumplen sin hacer ruido. Pregunta si alguno superó su línea base y la respuesta honesta suele ser: nunca la medimos, así que no lo sabemos. Fijar la línea base primero, y volver a medirla a medida que el modelo mejora, elimina esa ambigüedad.
Contabilidad de energía y coste
La mayoría de las discusiones sobre el coste de la IA se centran hoy en el coste por token. Es necesario, pero no suficiente. Lo que importa para la comparación energética es el coste completo de energía e infraestructura: tiempo de GPU, refrigeración, salida de datos, orquestación de consultas, infraestructura de evaluación. Una definición que pone la energía al mismo nivel que la calidad del resultado obliga a que esa contabilidad exista de verdad.
Versión práctica: para cualquier iniciativa de IA deberías poder responder «cuánta energía consume el sistema por resultado útil y cómo se compara con la línea base humana haciendo la misma tarea». Si no puedes, todavía no estás listo para pasar a producción: estás listo para instrumentar.
La «intervención humana excepcional» descarta la mayoría de los despliegues
Hay una cláusula enterrada en la definición que hace mucho trabajo: con intervención humana solo excepcional. La nota aclaratoria precisa que «excepcional» significa reorientar el software en situaciones matemáticas que rompen sus aproximaciones.
En términos de ingeniería: un flujo constante de prompt engineering, ajuste de pipelines RAG, filtrado de salidas y corrección con un humano en el bucle no es intervención excepcional. Es intervención rutinaria. Un sistema que necesita intervención humana rutinaria para producir resultados útiles es, según esta definición, software de IA en desarrollo, no IA desplegada.
Esto importa porque la mayoría de los «despliegues de IA» que veo en 2026 siguen en el régimen de intervención rutinaria. Producen salidas que necesitan curación humana para ser fiables. Es una etapa de desarrollo legítima, pero llamar «IA desplegada» a esos sistemas tergiversa el coste operativo. Adoptar esta definición obliga a ser honestos sobre qué sistemas se han graduado de verdad.
De qué te aleja esta definición
Algunas cosas se vuelven más difíciles de sostener en cuanto adoptas este encuadre:
«IA por la IA». Si el sistema no supera la línea base humana en calidad, velocidad o energía, el despliegue no produce valor. Eso no significa matarlo: puede ser un peldaño hacia un sistema que sí lo haga. Pero hay que etiquetarlo honestamente como I+D, no como IA en producción.
«La IA como casilla de funcionalidades». Poner en el producto un botón con un LLM detrás porque la competencia tiene uno es legítimo como marketing. No es, según esta definición, un despliegue de IA, porque no hay una mejora medida contra una línea base. No lo presupuestes como si lo fuera.
Las afirmaciones de arquitectura de «salto cuántico». La definición es agnóstica respecto a la arquitectura. Un algoritmo clásico bien afinado que supera a una línea base neuronal con menos coste energético es, según esta definición, más IA que la línea base neuronal a la que sustituyó. Es un correctivo útil contra la suposición de que más grande y más complejo es siempre más IA.
Qué te permite defender esta definición
También vuelve defendibles algunas posiciones poco de moda.
Una consulta SQL de 200 líneas que supera de forma consistente a un analista júnior en una clase concreta de informes, se ejecuta en segundos y cuesta céntimos por ejecución es, según esta definición, IA. Analiza datos, produce resultados mejores que la línea base profesional media, más rápido y con menos coste energético que las alternativas con línea base humana. Que no sea una red neuronal es irrelevante.
Conozco la objeción: si una consulta SQL cuenta como IA, la palabra deja de significar nada. No es así: la prueba de la línea base es el filtro, y la mayoría del software jamás supera de forma rutinaria a un profesional en nada. Esto no es una floritura retórica. Es una postura práctica. La consulta SQL hace el trabajo. La alternativa cara basada en un LLM podría hacerlo peor y más lento, a un coste mayor. Adoptar la definición te permite poner en producción la consulta SQL y decir, sin sonrojarte, que has desplegado IA — sin el tono de disculpa de que la IA «de verdad» exige arquitecturas neuronales.
Qué haría yo con esto
Tres acciones concretas para el trimestre:
- Para cada sistema que hoy llamas «IA», escribe su línea base humana. Calidad, velocidad y energía. Si no puedes, todavía no sabes si el sistema pasa el listón.
- Presupuesta por separado la IA de marketing y la IA de producción. Si un sistema no supera de forma rutinaria una línea base, es I+D. Y la I+D va en un presupuesto de I+D, con expectativas de I+D.
- Añade la energía y el coste por resultado útil a tus dashboards de IA. Si tu roadmap de IA tiene presupuesto pero no telemetría de coste por resultado, vuelas a ciegas justo en la parte de la definición que condiciona la viabilidad a largo plazo.
Las definiciones de manual existen por continuidad académica. La definición de ingeniería existe para tomar mejores decisiones de despliegue. Merece la pena adoptar una de cada.
Fuente: Fradelos, G. Updated Definition of Artificial Intelligence (Ginebra, 14 de diciembre de 2025). SSRN 6292000.
Si tu roadmap de IA está lleno de pilotos y escaso de sistemas en producción que de verdad superan su línea base, habla con un CTO sobre desplegar capacidad de ingeniería centrada en resultados de IA medibles, no en demos.
