Hacer IA para decir que tenemos IA

Una proporción creciente de iniciativas de IA empresarial no parten de un problema. Parten de la necesidad de ser vistos usando IA. El resultado es espectáculo: costo, riesgo y complejidad en busca de un caso de uso, con el chatbot, el copiloto y el buscador «inteligente» cumpliendo todos el mismo papel – una señal visible de impulso, ligera en arquitectura, responsable ante nadie en particular.

Una empresa no siempre adopta IA porque haya encontrado una oportunidad. A veces adopta IA porque el mercado está mirando, los competidores están anunciando cosas, la junta directiva pregunta por modelos generativos, los proveedores empujan demos y alguien necesita una captura de pantalla que demuestre progreso. Entonces aparece el chatbot. O el asistente interno. O el copiloto improvisado. O el buscador «inteligente». O un flujo de trabajo con IA pegada por encima. No necesariamente porque haga falta. Porque es visible.

El problema no es usar IA. El problema es usar IA como señal de estatus. La IA colocada deliberadamente, con alcance bien definido y conectada a un flujo de trabajo real puede crear valor significativo. La IA desplegada para que la organización pueda decir que tiene IA es una manera cara de confundir movimiento con progreso, y la factura es más amplia de lo que parece al momento del lanzamiento.

Este artículo trata de esa brecha.

La presión por parecer nativos de la IA

Varias presiones convergen al mismo tiempo. Los competidores anuncian IA. Los inversionistas preguntan por IA. Las juntas directivas preguntan si la empresa tiene una estrategia de IA. Los proveedores llegan con demos pulidos. Las conferencias y las redes sociales amplifican el extremo visible de la curva. Internamente, los líderes sienten la necesidad de mostrar impulso, y los colaboradores individuales sienten la necesidad de ser vistos trabajando en algo moderno.

Bajo esa presión, la pregunta que se hace primero rara vez es la correcta. La organización empieza preguntando: «¿Dónde podemos poner IA?» antes de haber preguntado: «¿Qué problema realmente merece IA?». La primera pregunta es un ejercicio de aprovisionamiento. La segunda es una estrategia.

La pregunta inicial equivocada

«¿Cómo agregamos IA?» es la pregunta que produce espectáculo. La forma de la respuesta está predeterminada: una funcionalidad, una superficie, un demo. La forma del problema es lo que sobra cuando el demo ya está construido.

La mejor pregunta, la que produce estrategia, es la inversa. ¿Qué problema es lo bastante importante, frecuente, costoso o complejo como para justificar IA? ¿Dónde se está tomando hoy una decisión mal? ¿Dónde un flujo de trabajo quema tiempo, atención o precisión? ¿Dónde hay un usuario atascado esperando a que alguien más haga algo que un modelo podría hacer bien, con controles, bajo supervisión?

La IA no es el punto de partida. El problema lo es. La IA es una opción para resolver el problema, evaluada contra reglas, software tradicional, automatización, búsqueda, formularios, mejora de procesos y la posibilidad aburrida de que el problema ya esté resuelto con datos más limpios o responsabilidades más claras.

El espectáculo de IA se ve como progreso

Las iniciativas de IA teatrales son difíciles de matar porque parecen liderazgo. Son fáciles de presentar en una diapositiva. Producen demos convincentes. Generan impulso. Satisfacen a la junta. Son difíciles de criticar sin sonar antiinnovación. Permiten a la organización decir que está haciendo algo.

Eso es exactamente lo que las hace peligrosas. La señal de progreso está desacoplada de la sustancia del progreso. Para cuando la brecha se hace visible – en la factura, en una captura de pantalla, en una decisión de tribunal, en una revisión de seguridad que debió haber ocurrido antes – el costo político de retirar el sistema es más alto que el costo de dejarlo corriendo. La organización ahora está en el negocio de defender algo que nunca decidió construir.

El chatbot es el síntoma más visible

Los chatbots no son el problema completo. Son el síntoma más fácil de capturar en una pantalla. Un asistente público pulido en la página de inicio corporativa es la foto canónica del patrón: una superficie de IA que llegó antes que su arquitectura.

Los casos conocidos siguen la misma forma. El chatbot de un concesionario aceptó, en cámara, vender un vehículo por un dólar. El asistente público de una empresa de mensajería produjo resultados inapropiados y criticó a su propio empleador con la voz de la empresa. El chatbot de una aerolínea le dio información engañosa a un cliente, y un tribunal responsabilizó a la aerolínea por la respuesta. Ninguna de esas son historias sobre investigación adversarial de IA. Son historias sobre el símbolo de innovación llegando antes que la arquitectura, y el público descubriendo la brecha antes que la empresa.

El chatbot es conveniente porque es visible. La misma brecha aparece donde sea que se despliegue IA por la captura de pantalla en lugar de por el problema: un copiloto interno del que nadie es responsable, un buscador «inteligente» atornillado a un corpus de documentos sin organizar, un flujo de trabajo con IA pegada encima de un proceso que ya estaba roto, un complemento de proveedor instalado sin que nadie acordara qué debe negarse a hacer. Superficies distintas, la misma brecha.

El hype se salta las preguntas aburridas

Cuando una iniciativa de IA arranca desde el FOMO, un conjunto reconocible de preguntas se salta. Son las preguntas donde vive la arquitectura. Naturalmente, también son las primeras que se cortan cuando todo el mundo quiere lo brillante.

¿Qué problema resuelve esto? ¿Por qué IA, y no software tradicional? ¿Qué debe negarse a hacer el sistema? ¿Quién es responsable de él? ¿Cuánto cuesta cada interacción? ¿Qué pasa cuando se equivoca? ¿Qué pasa cuando los usuarios abusan de él? ¿Qué datos puede usar? ¿Qué decisiones no se le permite tomar? ¿Cómo medimos el éxito en términos operativos, no en métricas vagas de engagement? ¿Cuándo lo apagaríamos?

Ninguna de esas preguntas es exótica. Son las mismas preguntas que cualquier capacidad pública seria tiene que responder. El hecho de que las superficies de IA rutinariamente se las salten no significa que la IA se haya ganado la exención. Significa que la exención se concedió informalmente, y se revocará públicamente.

La factura de la API llega después

La factura literal de la API es la parte más pequeña de la factura. Es la más fácil de medir, por eso se lleva los titulares, pero rara vez es donde aterrizan los costos más grandes.

La factura completa incluye el costo de inferencia, sí – prompts largos, completions largos, llamadas de recuperación, llamadas a herramientas, registros verbosos, y el patrón de denegación de cartera en el que una superficie pública corriendo sobre un modelo pagado se convierte en un proxy gratuito de ese modelo y las comunidades en línea se acomodan para pasar la tarde. También incluye la carga de soporte creada por usuarios que tratan al bot como una interfaz autoritativa, la deuda operativa de monitorear un sistema que nadie diseñó para ser monitoreado, el costo de marca cuando la salida generada se convierte en una captura de pantalla, la exposición legal cuando un canal hacia el cliente compromete a la empresa con algo que no pretendía comprometer, el costo de seguridad de una superficie de producción pública que nadie dimensionó para entrada adversarial, el lock-in con el proveedor que sigue cuando los cambios de política del proveedor del modelo alteran el comportamiento del producto, el costo de mantenimiento de contenido para mantener frescas las fuentes del bot, la atención de ingeniería desviada de trabajo que sí habría movido el negocio real, y las falsas expectativas sembradas en usuarios y liderazgo cuando un demo de IA se presenta como un sistema terminado.

La factura del hype se paga en dinero, reputación, operación, confianza, gobierno y atención de ingeniería. La factura del modelo es la línea que la gente recuerda; el resto son las líneas que no.

La verdadera estrategia de IA es menos fotogénica

La IA empresarial valiosa tiende a empezar en lugares que no se ven bien en una captura de pantalla. Clasificación de tickets. Resumen de casos. Búsqueda interna sobre fuentes aprobadas. Asistencia a analistas y revisión de documentos. Extracción de datos desde entradas desordenadas. Detección de anomalías en lugares donde los humanos dejan de escalar. Generación controlada de borradores detrás de un revisor humano. Soporte a la decisión que hace al humano mejor, no ausente.

La forma es consistente. Una definición acotada del trabajo con no-objetivos explícitos. Un flujo de trabajo cuyo dolor, costo, demora o tasa de error está documentado antes de que se elija el modelo. Un responsable con nombre en el rol. Fuentes de datos aprobadas con cadencia de actualización. Comportamiento de rechazo intencional y probado, no una propiedad emergente de un system prompt. Controles de costo y tasa cableados desde el primer día. Comportamiento observable, con registros y prompts de red team como parte de la suite de pruebas. Un ciclo de vida documentado, incluidas las condiciones bajo las cuales el sistema se apaga.

Nada de eso se ve bien en una captura de pantalla. Ese es el punto. La captura era la meta del espectáculo. El sistema tiene que vivir después.

A veces la mejor decisión de IA es todavía no usar IA

No todo problema merece un modelo. Algunos problemas necesitan arquitectura, datos más limpios, responsabilidades más claras, mejor proceso o disciplina operativa. Esas intervenciones son trágicamente poco glamorosas, y a menudo son las correctas.

Mejorar la base de conocimiento antes de agregar un chatbot, porque un chatbot apuntado a un corpus desactualizado o contradictorio hereda las contradicciones y paga por consulta para repetirlas. Limpiar los datos antes de automatizar el análisis, porque un modelo entrenado con entradas sucias hace inferencias sucias más rápido, no mejor. Estandarizar el proceso antes de construir copilotos, porque un copiloto atornillado a un proceso inconsistente amplifica la inconsistencia. Crear APIs internas antes de desplegar agentes, porque los agentes sin una superficie contratada terminan haciendo scraping de la empresa. Instrumentar métricas antes de optimización predictiva, porque los modelos no pueden optimizar lo que no se mide. Mejorar la búsqueda tradicional antes de agregar generación, porque generación sobre un índice pobre es generación de respuestas pobres. Arreglar la responsabilidad antes de agregar automatización, porque la automatización amplifica a quien sea que esté a cargo, incluyendo a nadie.

Algunos problemas merecen una regla, no un modelo. Algunos merecen un formulario. Algunos merecen una conversación entre dos personas cuyos calendarios simplemente no coinciden. La disciplina es elegir deliberadamente, no caer por defecto en la IA porque todos los demás lo hacen.

La prueba de arquitectura

Una prueba práctica separa estrategia de espectáculo. Ninguna de estas preguntas requiere un modelo para ser respondida. Cada una es un sí o un no. Cuantas menos respuestas afirmativas, más la iniciativa es espectáculo disfrazado de estrategia.

• Si quitáramos la palabra «IA», ¿el problema seguiría importando?
• ¿Los usuarios necesitaban esto antes del ciclo de hype?
• ¿Tenemos evidencia de dolor, costo, demora, riesgo o error?
• ¿Es la IA la mejor solución, o solo la más vendible?
• ¿Sabemos cómo se ve la falla?
• ¿Sabemos qué nunca debe hacer el sistema?
• ¿Podemos medir valor dentro de noventa días?
• ¿Hay un responsable operativo con nombre asignado?
• ¿Hay límites de costo y uso, fijados antes del lanzamiento?
• ¿Hay una manera segura de apagarlo?

La prueba es deliberadamente poco generosa. El espectáculo es difícil de matar una vez lanzado; es mucho más fácil negarse a lanzarlo.

Lo que el liderazgo debe exigir

La jugada de liderazgo no es pedir más IA. Es pedir la disciplina que convierte la IA en valor.

El liderazgo de IA maduro exige casos de uso atados a valor real. Enunciados de problema claros, escritos antes de elegir el modelo. Fronteras de arquitectura que nombran qué nunca debe hacer el sistema. Impacto medible dentro de una ventana definida. Límites explícitos sobre costo, uso, alcance y autoridad. Responsabilidad con nombre en la página. Un análisis de riesgo que incluye exposición de marca, legal, seguridad y operativa. Costo total de operación, no solo la factura del modelo. Criterios de apagado, acordados antes del lanzamiento. Evidencia de que la IA es la respuesta correcta, sopesada contra alternativas más simples que a veces la organización no quiere revisar porque la conversación sobre IA es más interesante.

El conteo de superficies es una métrica de vanidad. La disciplina operativa es la capacidad real. La cantidad de lugares donde la empresa ha puesto IA es una señal mucho más débil que cuán deliberadamente se ha colocado IA donde puede crear valor de forma segura.

Después de la captura de pantalla

La pregunta superficial es si la empresa tiene IA. Las mejores preguntas son si la necesitamos aquí, qué problema resuelve, qué valor debe crear, qué tiene prohibido hacer, qué cuesta cuando la gente la usa mal, quién es responsable del resultado, y qué pasa después de la captura de pantalla.

La IA no solo falla cuando alucina, cuando es manipulada o cuando cuesta demasiado. También falla cuando nunca debió haberse desplegado en primer lugar. La organización madura no empieza con «¿dónde podemos poner IA?». Empieza con «¿qué problema merece IA, qué valor esperamos, qué límites necesita, y quién es responsable del resultado?».

El espectáculo de IA quiere la captura de pantalla. La buena arquitectura pregunta si el sistema debe existir después de la captura.

Notas de fuentes

Las fuentes se listan en el orden en que el artículo las usa. Las dos primeras anclan el argumento estratégico: investigación independiente sobre por qué fallan las iniciativas de IA, y la lectura desde la industria del ciclo de hype que ubica esas iniciativas a media caída desde las expectativas infladas hacia el valle de la desilusión. Las tres siguientes son incidentes públicos, reposicionados aquí como síntomas del símbolo-de-innovación que llega antes que la arquitectura que debería sustentarlo. Las dos últimas son las preocupaciones arquitectónicas que el artículo trata como líneas de la factura del hype, no como su tesis.

• RAND, «The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed» (2024). Ancla la tesis de fracaso conducido desde el liderazgo. Basado en 65 entrevistas semiestructuradas con científicos de datos e ingenieros de ML experimentados, el reporte encuentra que el 84 por ciento de las fallas son conducidas desde el liderazgo, con las causas raíz más comunes siendo malentender o comunicar mal qué problema se supone que el sistema debe resolver, aplicar IA a problemas que herramientas más simples podrían resolver, y la presión sobre los gerentes para «hacer algo —cualquier cosa— con IA para demostrar a sus superiores que están al día». Usado como cita primaria del patrón de adopción FOMO/conducido por hype que este artículo llama espectáculo de IA. Fuente: Ryseff, De Bruhl, Newberry, «The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed: Avoiding the Anti-Patterns of AI», RAND RR-A2680-1 (ago 2024).
• Gartner, «Hype Cycle for Generative AI» (2025). Lectura desde la industria del mismo patrón. Gartner ubica a la IA generativa pasado el Pico de Expectativas Infladas y dentro del Valle de la Desilusión, señalando que «las innovaciones con promesas elevadas están luchando por cumplir las expectativas infladas y por moverse de la prueba de concepto a la producción». Usado como evidencia de apoyo de que el espectáculo de IA está ampliamente reconocido como patrón, no como queja aislada. Fuente: Chandrasekaran, «The 2025 Hype Cycle for GenAI Highlights Critical Innovations», Gartner (jul 2025).
• Incidente del chatbot del concesionario Chevrolet. Usado para ilustrar una superficie pública de IA lanzada sin alcance, sin diseño de rechazo y sin autoridad definida, incluido el intercambio ampliamente circulado del «acuerdo de vender una Tahoe por un dólar». Citado como evidencia de un símbolo de innovación que entró en vivo antes que la arquitectura que debió sustentarlo – no como afirmación de que la salida de un chatbot cree contratos vinculantes. Fuente: Gizmodo, «I’d Buy That for a Dollar: Chevy Dealership’s AI Chatbot Goes Rogue» (dic 2023).
• Incidente del chatbot de DPD. Usado para ilustrar la exposición de marca cuando un asistente público produce salidas inapropiadas o autocríticas. La lección es operativa, no técnica: el símbolo de innovación entró en vivo sin el modelo operativo que las superficies públicas requieren. Fuente: The Guardian, «DPD AI chatbot swears, calls itself ‘useless’ and criticises delivery firm» (ene 2024).
• Decisión del tribunal en el caso del chatbot de Air Canada. Usada para ilustrar que las empresas siguen siendo responsables de las respuestas que dan sus canales oficiales, incluidas las respuestas de chatbot. Tratada como advertencia sobre responsabilidad y rendición de cuentas, no como reclamo legal generalizado. Fuentes: Moffatt v. Air Canada, 2024 BCCRT 149 (Civil Resolution Tribunal of British Columbia); BBC, «Airline held liable for its chatbot giving passenger bad advice» (feb 2024).
• OWASP Top 10 para aplicaciones de LLM — LLM01: Prompt Injection. Citado porque el prompt injection es uno de los mecanismos por los cuales la ausencia de arquitectura se hace visible en una superficie pública de IA. Los despliegues teatrales tienden a descubrir, en producción, que un system prompt no es un límite de seguridad. Fuente: OWASP GenAI Security Project — LLM01: Prompt Injection.
• OWASP Top 10 para aplicaciones de LLM — LLM10: Unbounded Consumption. Citado porque el costo es una de las líneas en las que se paga la factura del espectáculo. Una superficie pública corriendo sobre un modelo pagado sin límites es un medidor que los extraños pueden hacer girar. Fuente: OWASP GenAI Security Project — LLM10: Unbounded Consumption.