Hacer IA para decir que tenemos IA

Algunas iniciativas empresariales de IA empiezan por la necesidad de ser vistos usando IA, no por un problema definido. El chatbot, el copiloto o el buscador «inteligente» se convierte en una señal visible de impulso antes de que alguien nombre el flujo, el responsable, los límites o la medida de valor.

El problema no es usar IA. Una IA deliberada, acotada y conectada a un flujo real puede crear valor. El problema es usarla como señal de estatus. Esa elección convierte una demostración en compromiso operativo antes de que la organización decida para qué existe el sistema.

Una prueba útil es si la iniciativa todavía tiene sentido sin el anuncio de lanzamiento. Si su valor depende principalmente de ser visible, la organización está optimizando la señal antes de diseñar la capacidad que debe permanecer cuando la atención pase a otra cosa.

Por qué empieza el espectáculo de IA

Los competidores anuncian IA. Las juntas preguntan por la estrategia. Los proveedores traen demos pulidos. Los líderes quieren evidencia de impulso. Bajo esa presión, la organización pregunta «¿dónde podemos poner IA?» antes de preguntar «¿qué problema merece IA?».

La primera pregunta predetermina la respuesta: una funcionalidad, superficie o demo. La segunda permite comparar la IA con reglas, software tradicional, automatización, búsqueda, mejora de procesos y la posibilidad de que el problema real sea la mala calidad de datos o una responsabilidad difusa.

La evidencia descriptiva no debe confundirse con prueba causal. Las encuestas laborales de Gallup documentan un mayor uso de IA en el trabajo. No establecen por qué una organización concreta inicia un proyecto ni por qué falla. El informe de RAND de 2024 parte de 65 entrevistas con científicos de datos e ingenieros de ML experimentados e identifica antipatrones de liderazgo, incluidos problemas poco claros y presión por demostrar actividad con IA. La muestra sustenta un patrón creíble, no una tasa universal de fracaso para toda iniciativa empresarial.

El espectáculo persiste porque parece progreso. Un demo es fácil de presentar y difícil de criticar sin parecer resistente a la innovación. Después del lanzamiento, los costos políticos y operativos dificultan retirar el sistema. La organización empieza a defender una capacidad que nunca decidió construir por completo.

La superficie pública revela la arquitectura ausente

Los chatbots públicos no son todo el problema. Son la escena más clara porque los clientes pueden probar la brecha directamente. El asistente de DPD produjo contenido inapropiado y criticó a la empresa. El chatbot de Air Canada dio orientación incorrecta a un cliente, y el Civil Resolution Tribunal de Columbia Británica responsabilizó a la aerolínea por la información presentada a través de su canal.

Estos incidentes no prueban que todo chatbot sea imprudente ni que el texto generado tenga autoridad ilimitada. Muestran un punto más acotado: una superficie pública de IA hereda las responsabilidades de un sistema público en producción. Alcance, comportamiento de rechazo, fuentes aprobadas, escalamiento, monitoreo y responsabilidad deben existir antes del lanzamiento.

La misma brecha aparece dentro de la empresa: un copiloto sin responsable, generación sobre una base de conocimiento desactualizada o un agente conectado a flujos sin interfaces contratadas. La superficie cambia. Las preguntas arquitectónicas no.

La advertencia más fuerte de los incidentes públicos no es que un chatbot haya usado lenguaje sorprendente. Es que las organizaciones habían creado canales oficiales cuyos límites no eran claros para usuarios y, en algunos casos, para las propias organizaciones. Una superficie de producción necesita un propósito aprobado, una fuente de verdad definida, una ruta hacia una persona y un plan de respuesta para salidas fuera del alcance previsto.

Eso no vuelve incorrecta a toda IA orientada al cliente. Un asistente acotado sobre información mantenida, con límites visibles y escalamiento confiable, puede reducir fricción. El riesgo aumenta cuando la interfaz implica competencia amplia, usa generación abierta para políticas u orientación transaccional, o permite que respuestas fluidas excedan la autoridad real del sistema.

Los copilotos internos merecen la misma disciplina aunque sus fallas sean menos públicas. Un resumen inexacto puede entrar al registro de un caso. El código generado puede cargar una suposición insegura. Una respuesta de búsqueda puede omitir el documento que cambia la decisión. El efecto puede aparecer como reproceso silencioso en lugar de captura viral, lo que vuelve más importantes la medición y la responsabilidad.

El cargo directo del modelo puede ser material, pero es solo una parte del costo total. Los demás costos incluyen recuperación y llamadas a herramientas, abuso de consumo, soporte, monitoreo, mantenimiento de contenido, pruebas de seguridad, revisión legal, cambios de proveedor, respuesta a incidentes y atención de ingeniería desviada de trabajo con mayor valor.

El peso relativo de esos costos depende del sistema. La disciplina importante es estimarlos antes del lanzamiento, en lugar de tratar la factura de la API como el caso de negocio completo.

La estrategia empieza por un problema y un modelo operativo

La IA empresarial valiosa suele empezar en trabajo menos visible: clasificación de tickets, resumen de casos, búsqueda sobre fuentes aprobadas, revisión de documentos, extracción de datos, explicación de anomalías o redacción controlada detrás de una persona revisora calificada.

La forma común es acotada. El dolor, retraso, costo o tasa de error del flujo se documenta antes de elegir el modelo. El trabajo tiene no-objetivos explícitos. Las fuentes de datos y su cadencia de actualización están aprobadas. El rechazo y el escalamiento se prueban. Existen límites de costo y uso. Una persona responsable puede explicar el éxito, la falla y las condiciones de apagado.

A veces la decisión correcta es no usar IA todavía. Una base de conocimiento desactualizada necesita mantenimiento antes que generación. Los procesos inconsistentes necesitan estandarización antes que copilotos. Los agentes necesitan interfaces estables, no scraping improvisado. Los sistemas predictivos necesitan resultados medidos. La automatización necesita responsable.

Las entradas deficientes afectan a los sistemas de formas distintas: los datos de entrenamiento pueden moldear el modelo, los datos recuperados pueden moldear una respuesta y los datos de evaluación pueden ocultar fallas. La respuesta no es la instrucción vaga de «limpiar los datos». Es identificar qué datos entran en cada etapa, quién los mantiene y cómo se prueba su calidad.

Un plan de producción también debe distinguir el modelo del sistema que lo rodea. La recuperación, los prompts, las herramientas, los permisos, la interfaz, la revisión, la telemetría y el soporte afectan el resultado. Elegir el modelo importa, pero un puntaje de benchmark no responde quién puede usar la capacidad, qué registros puede alcanzar ni qué ocurre cuando cambia una dependencia externa.

Esa distinción explica por qué muchos demos engañan. Un ejemplo controlado usa entradas seleccionadas, un usuario cooperativo y una ruta preparada. Producción trae registros desactualizados, solicitudes ambiguas, dependencias inaccesibles, picos de demanda, entrada adversarial, excepciones y personas que interpretan una salida fluida como autoritativa. La brecha no demuestra que la IA no pueda funcionar. Demuestra que el demo no probó el sistema operativo que la rodea.

El costo necesita la misma visión de sistema. La inferencia, la recuperación y las llamadas a herramientas son costos variables. La evaluación, observabilidad, pruebas de seguridad, mantenimiento de contenido, revisiones de acceso, respuesta a incidentes y soporte son costos operativos. La integración, migración y cambios de proveedor son costos de ciclo de vida. Una estimación útil separa esas categorías y las vincula con volumen, niveles de servicio y manejo de errores.

Las superficies públicas agregan exposición de marca y legal porque el texto generado aparece con la voz de la organización. Los sistemas internos agregan otro riesgo: las personas pueden encaminar decisiones de forma silenciosa por un asistente cuya autoridad nunca se definió. En ambos casos, etiquetar la salida como IA no resuelve la responsabilidad. La interfaz debe comunicar incertidumbre, uso aprobado, escalamiento y el punto donde una persona debe decidir.

La revisión humana no es una salvaguarda universal. Quien revisa necesita contexto, competencia, tiempo y autoridad para rechazar el resultado. Si debe aprobar gran volumen o no puede inspeccionar la evidencia detrás de una respuesta, el paso de revisión puede transferir responsabilidad sin agregar control. El diseño debe especificar qué ve la persona revisora, qué debe comprobar y qué ocurre después del rechazo.

Los agentes elevan el riesgo porque pueden actuar mediante herramientas. Una API estable no hace segura una acción por sí sola, pero crea un contrato que puede autorizarse, registrarse, probarse, limitarse y revocarse. Automatizar una interfaz construida para personas es más frágil y difícil de acotar. La secuencia correcta es definir primero el límite de acción y luego decidir si un modelo debe operar dentro de él.

La medición debe empezar antes del piloto. Si el flujo actual no tiene una línea base de tiempo, calidad, costo, backlog o error, el equipo no puede distinguir mejora de novedad. Uso y satisfacción pueden ayudar, pero no reemplazan resultados operativos. Un asistente usado con frecuencia todavía puede crear reproceso; uno usado de forma acotada puede ser valioso si mejora una decisión costosa.

Por último, el sistema necesita ciclo de vida. Las personas responsables deben saber cuándo cambiar un prompt, reemplazar un modelo, actualizar una fuente, suspender una herramienta, avisar a usuarios o retirar la capacidad. Ese trabajo es menos visible que el lanzamiento. También es la diferencia entre un experimento del que la organización puede aprender y una superficie permanente que nadie se siente autorizado a quitar.

La prueba de arquitectura

Esta prueba separa un experimento útil de un proyecto de estatus. Cuantas más preguntas carezcan de una respuesta concreta, menos preparada está la iniciativa para convertirse en capacidad operativa.

• Si quitáramos la palabra «IA», ¿el problema seguiría importando?
• ¿Tenemos evidencia de dolor, demora, costo, riesgo o error?
• ¿Por qué la IA es mejor aquí que una alternativa más simple?
• ¿Qué nunca debe hacer el sistema?
• ¿Qué ocurre cuando el resultado es erróneo o se abusa del sistema?
• ¿Qué datos puede usar y quién los mantiene?
• ¿Podemos medir valor dentro de una ventana definida?
• ¿Quién responde por la operación, los incidentes y los efectos posteriores?
• ¿Los límites de costo y uso están fijados antes del lanzamiento?
• ¿Qué condición activa el apagado?

El liderazgo debe pedir estas respuestas, no un conteo mayor de superficies de IA. El conteo de superficies es una métrica de visibilidad. La disciplina operativa es la capacidad.

Notas de fuentes

• RAND, «The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed» (2024). Basado en 65 entrevistas semiestructuradas con científicos de datos e ingenieros de ML experimentados. El informe identifica antipatrones recurrentes de liderazgo, como problemas poco claros, uso de IA donde herramientas más simples podrían encajar y presión por demostrar actividad. El artículo trata esos hallazgos como evidencia cualitativa, no como estimación causal para toda la población. Fuente: RAND RR-A2680-1.
• Gallup, «AI Use at Work Has Nearly Doubled in Two Years» (2025). Evidencia de encuesta laboral que describe patrones de adopción y uso. Sustenta que el uso de IA en el trabajo crece; no establece por qué proyectos individuales empiezan o fallan. Fuente: Gallup Workplace.
• Gartner, «Hype Cycle for Generative AI» (2025). Encuadre de industria sobre la dificultad de pasar de expectativas infladas y pruebas de concepto a producción. Aporta contexto al patrón, no evidencia causal para fallas específicas. Fuente: Gartner.
• Incidente del chatbot de DPD. Evidencia de exposición operativa y de marca cuando un asistente público produce contenido inapropiado. Fuente: The Guardian (ene 2024).
• Decisión sobre el chatbot de Air Canada. Evidencia de que una organización puede seguir siendo responsable de la información entregada por su chatbot oficial. El artículo no generaliza la decisión del tribunal fuera de ese contexto. Fuentes: Moffatt v. Air Canada, 2024 BCCRT 149; BBC (feb 2024).
• OWASP Top 10 para aplicaciones de LLM. Prompt injection y consumo sin límites ilustran dos riesgos que los sistemas públicos de IA deben abordar mediante diseño y operación, no solo con un system prompt. Fuentes: LLM01: Prompt Injection; LLM10: Unbounded Consumption.