Antes de preguntar qué inteligencia artificial (IA) comprar, conviene preguntar por qué sigue existiendo una etapa que nadie sabe defender sin empezar con «siempre lo hicimos así».

TL;DR

No todo cuello de botella merece inteligencia artificial. A veces pide eliminar una etapa; otras, simplificarla, estandarizarla o automatizarla con una regla común. La IA de apoyo entra cuando el lenguaje, la ambigüedad o el volumen exigen de verdad interpretación. Un agente entra cuando el camino varía, necesita herramientas y su autonomía está delimitada. El diagnóstico va antes de la herramienta porque acelerar un proceso malo solo produce un proceso malo a mayor velocidad, y con una presentación bastante más cara.

Hay un ritual corporativo que se repite con una confianza impresionante.

Alguien encuentra una cola, retrabajo, una hoja de cálculo que nadie entiende o una persona que ha pasado la vida copiando datos de una pantalla a otra. La empresa mira la escena, respira hondo y anuncia la solución contemporánea:

«Tenemos que poner IA aquí».

Quizá la necesite.

Pero quizá la operación necesite dejar de pedir que alguien imprima, revise, firme, escanee y reenvíe un documento que ya nació digital. Quizá necesite una regla clara. Quizá dos sistemas necesiten hablar entre sí. Quizá necesite admitir que una decisión provisional de 2017 echó raíces y nadie tuvo el valor de preguntar por qué.

Poner IA encima de eso puede ser usar una bazuca para matar una mosca. La mosca muere. La oficina también se queda sin ventana.

No escribo esto para convertir «no usar IA» en una pose de sobriedad técnica. Trabajo precisamente construyendo software, automatización y sistemas asistidos por IA. El punto es otro: la tecnología es elegir cómo se organizan las partes de un sistema, sus conexiones y sus responsabilidades — su arquitectura de software. No es una medalla de modernidad. Y esa arquitectura empieza entendiendo el problema que existe, no celebrando la herramienta que acaba de aparecer en un video de demostración.

El problema no es la herramienta. Es la pregunta perezosa

En Tu empresa no necesita descubrir dónde poner IA, defendí empezar por el lugar donde se atasca el trabajo. Este texto da un paso anterior: antes de decidir dónde entra la IA, necesitamos decidir si debería entrar.

Porque «¿dónde ponemos IA?» muchas veces es una forma elegante de evitar preguntas menos fotogénicas:

• ¿qué resultado produce realmente esta etapa?
• ¿quién usa ese resultado y qué pasa si llega tarde o equivocado?
• ¿qué decisión respalda la etapa?
• ¿qué cambia si simplemente deja de existir?
• ¿la regla ya se conoce o estamos llamando inteligencia a la confusión?

Una herramienta puede esconder esas preguntas por un tiempo. No puede responderlas por nosotros.

Cuando la respuesta es «nadie sabe, pero siempre lo hicimos así», todavía no tenemos un caso de uso de IA. Tenemos una investigación.

El orden de intervención que evita el teatro tecnológico

Suelo pensar en seis salidas posibles. No son una escalera obligatoria; un proceso puede combinar más de una. Pero el orden ayuda a que la complejidad no se convierta en currículum.

1. Eliminar

La pregunta más infravalorada de una reunión de procesos es: ¿esto necesita existir?

Una aprobación duplicada, un informe que nadie lee, una copia manual hecha «por seguridad» y una comprobación creada para compensar otro error pueden parecer pequeños. Juntos, se convierten en un departamento informal dedicado a mantener el pasado.

Eliminar una etapa no es pereza. Es diseño de procesos. Si no protege un riesgo, no produce una decisión, no cumple una obligación real y no entrega valor a nadie, la solución más elegante puede ser retirarla.

Ningún sistema entrenado para procesar y producir texto — un modelo de lenguaje — supera una tarea que ya no existe.

2. Simplificar

A veces la etapa tiene una razón, pero se volvió rebuscada porque cada excepción recibió un parche. Una persona rellena cinco campos para que otra descubra después que solo necesitaba dos. El formulario exige una descripción larga para terminar en «urgente». El flujo cruza tres sistemas porque nadie tuvo tiempo de definir dónde debe mantenerse la información como referencia — la llamada fuente de verdad.

Simplificar es reducir pasos, campos, aprobaciones y transferencias hasta que quede lo necesario. No es debilitar el control. Es hacer que el control sea proporcional al riesgo.

Usar un cuchillo para apretar un tornillo puede funcionar en un apuro. Construir todo el proceso alrededor del cuchillo es solo una manera creativa de asegurar que alguien se lastime después.

3. Estandarizar

Hay trabajo que parece complejo solo porque cada persona lo hace de una forma.

Estandarizar significa hacer explícitos la entrada, el criterio, el responsable, la excepción y el resultado. Es definir qué significa «pedido listo» antes de crear una IA que adivine si el pedido está listo. Es registrar la política antes de pedir a un agente que la aplique. Es decidir dónde vive la información antes de crear una búsqueda sobre cinco versiones contradictorias de ella.

La estandarización no exige que cada situación se vuelva rígida. Separa el camino común de la excepción que merece análisis humano.

4. Automatizar con una regla

Cuando se conocen la entrada, la regla y el resultado, la mejor respuesta suele ser un sistema que ejecuta la misma regla en las mismas condiciones — una automatización determinista.

Si el pago está confirmado, actualiza el estado. Si falta un campo obligatorio, bloquea el envío. Si vence un plazo, avisa a la persona responsable. Si termina la copia de seguridad (backup), registra el resultado.

No necesitamos IA para sumar valores, transferir datos entre sistemas o validar una condición objetiva. Usar un sistema que elige resultados según probabilidades calculadas a partir de patrones aprendidos, en lugar de limitarse a ejecutar una regla fija — un modelo probabilístico — puede volver el resultado menos previsible, más difícil de probar y más caro de operar. Es impresionante de la misma forma que una tostadora con panel de avión es impresionante: alguien trabajó mucho, pero sigue siendo una tostada.

5. Usar IA como apoyo

La IA empieza a tener sentido cuando hay lenguaje, ambigüedad o volumen que una regla aislada no resuelve bien.

Puede resumir un historial largo, extraer campos de documentos variados, clasificar solicitudes, comparar versiones de texto, localizar información relevante o producir un análisis inicial para que una persona lo revise.

Aquí la IA no recibe autoridad para «resolverlo todo». Reduce trabajo cognitivo, organiza material y mejora la siguiente decisión. La persona sigue siendo responsable de lo importante; la herramienta le ayuda a ver mejor.

Este diseño resulta especialmente útil cuando la respuesta necesita contexto, pero el resultado todavía requiere revisión humana. Es apoyo, no abdicación.

6. Usar un agente, pero con contrato

Un agente de IA no es un chatbot con valentía. Es un sistema que combina contexto, herramientas y criterios para elegir los siguientes pasos dentro de un espacio delimitado.

Puede consultar datos, reunir evidencias, completar formularios y registros, abrir una tarea, pedir una información ausente o ejecutar una acción permitida. El camino puede variar según el caso; por eso los controles también deben crecer.

Antes de dar ese paso, quiero saber:

• qué herramientas puede usar el agente;
• qué acciones jamás puede ejecutar por sí solo;
• cuándo debe detenerse y pedir ayuda;
• cómo registra lo que consultó e hizo;
• cómo corregimos o deshacemos una acción;
• quién responde cuando el resultado no llega como se esperaba.

Sin eso, «agente autónomo» suele ser solo un nombre elegante para «nadie diseñó la responsabilidad todavía».

Un ejemplo menos glamuroso y mucho más útil

Imagina un equipo que recibe pedidos por correo electrónico. Alguien los lee, copia datos a una hoja de cálculo, pregunta por chat si hay stock, espera la respuesta, actualiza otro sistema y envía una confirmación estándar.

La reacción apresurada sería: «vamos a crear un agente de IA para atender los pedidos».

El diagnóstico puede revelar otra cosa:

1. la mitad de los pedidos ya podría usar un formulario que complete bien los campos;
2. el inventario tiene una interfaz de programación de aplicaciones (API), es decir, una forma documentada de que un sistema consulte a otro, y no necesita que alguien pregunte en el chat interno;
3. la confirmación estándar se puede enviar mediante una regla;
4. solo los pedidos con descripción ambigua o excepción comercial necesitan interpretación;
5. solo la excepción realmente relevante necesita llegar a una persona.

El diseño final puede tener un formulario mejor, integración de inventario, automatización común, IA de apoyo para texto libre y una cola humana para excepciones. Puede que no haya ningún agente ejecutor.

Eso no es una derrota para la IA. Es una victoria para la operación.

El objetivo no es instalar el componente más vistoso. Es quitar espera, errores y trabajo inútil sin crear una nueva bestia que alimentar.

La herramienta equivocada cobra intereses

Todo sistema tiene coste operativo: credenciales, integración, datos, monitorización, fallos, mantenimiento, formación, cambios de proveedor y personas que deben entender qué hacer cuando algo se sale del guion.

Una solución excesiva puede resolver el síntoma inicial y crear otro cuello de botella a su alrededor. El proceso que antes tenía una hoja de cálculo mala pasa a tener una hoja de cálculo mala, un agente sin contexto, una integración inestable, tres suscripciones mensuales y una reunión semanal para descubrir por qué respondió «con certeza» a una premisa inventada.

No es un argumento contra experimentar. Los experimentos pequeños, reversibles y medidos son como aprendemos. Pero un prototipo no se convierte en operación por ósmosis. Cuando algo empieza a afectar a clientes, dinero, datos personales, acceso o una decisión material, necesita responsable, criterio, observabilidad — señales que permiten entender qué hizo el sistema y diagnosticar fallos — y límites.

El AI Risk Management Framework del Instituto Nacional de Estándares y Tecnología de Estados Unidos (NIST) es voluntario y no dicta la arquitectura de una empresa. Sostiene algo más básico: el riesgo de IA debe considerarse en el diseño, desarrollo, uso y evaluación de un sistema. No basta con admirar el modelo; hay que gobernar el efecto que produce.

La pregunta que haría antes de cualquier demo

Si estoy hablando con una empresa sobre IA, no empiezo pidiendo acceso a la cuenta de algún proveedor. Empiezo localizando el trabajo real.

Pregunto dónde esperan las personas. Dónde repiten. Dónde necesitan buscar información. Dónde una decisión depende de la memoria. Dónde una excepción se convierte en incendio. Dónde alguien hace una etapa que sabe explicar, pero no sabe justificar.

Luego llega la pregunta que desmonta mucha ansiedad:

Si sacáramos la IA de la sala durante cinco minutos, ¿qué seguiríamos necesitando resolver?

Esa respuesta es el material de la arquitectura.

A veces apunta a una integración sencilla. A veces a una política mejor. A veces a automatización. A veces a IA de apoyo. A veces a un agente con límites claros. Y sí, a veces apunta a una etapa idiota que solo necesitaba una despedida educada.

En i-9.ai, comienzo con ese diagnóstico: entender qué está atascado, qué debe preservarse y cuál es la menor arquitectura capaz de producir un resultado verificable.

Si tienes un proceso que parece pedir IA, pero sospechas que solo está pidiendo atención, ponte en contacto. Puedes traer la hoja de cálculo fea. Suele contar más verdad que la demo bonita.

Sigue leyendo

• Tu empresa no necesita descubrir dónde poner IA: el mapa mayor para elegir proceso, automatización, IA de apoyo, agente o decisión humana.
• Los agentes genéricos pueden ser tu peor primer contacto con IA: por qué una solución lista sin contexto suele decepcionar antes de ayudar.
• La IA no es solo un generador de contenido para redes sociales: una visión más amplia de lo que la IA puede hacer cuando ya existe un problema real que resolver.

Referencias y límites de uso

• OpenTelemetry — ¿qué es OpenTelemetry? (What is OpenTelemetry?): documentación oficial sobre señales de telemetría, como trazas, métricas y registros, usadas para comprender sistemas en ejecución. Sustenta la explicación de observabilidad; no impone una herramienta ni una implementación concreta.
• NIST — marco de gestión de riesgos de IA (AI Risk Management Framework): referencia oficial para la gestión voluntaria de riesgos asociados a sistemas de IA. Sustenta considerar el riesgo durante el ciclo de vida; no prescribe el orden de intervención propuesto en este artículo ni certifica una implementación.

Los ejemplos son hipótesis de arquitectura destinadas a hacer visibles los criterios. No son casos de estudio, promesas de resultados ni sustituyen un diagnóstico técnico, jurídico, financiero, laboral o de seguridad en el contexto real.