La IA llega al negocio: qué cambia cuando cualquier área puede preguntarle a sus datos
Por Sebastián Grattarola — CTO de BigCheese, premier partner de AWS
En casi todas las organizaciones hay una escena que se repite. Alguien de comercial necesita preparar una reunión con un cliente y quiere saber qué se le entregó en el último proyecto. Desde operaciones quieren saber qué proyectos vienen atrasados. Alguien de la dirección quiere ver un indicador sin esperar al cierre del mes. Y en los tres casos la respuesta es la misma: pedírselo a otro, y esperar.
El cuello de botella no es la falta de datos. Los datos existen: están en el correo, en los documentos compartidos, en los sistemas de gestión, en el datalake. El cuello de botella es la disponibilidad, el acceso. La información está, pero llegar a ella requiere saber dónde buscar, tener permisos sobre cinco sistemas distintos o depender de que alguien del área de datos arme el reporte.
La IA generativa puede resolver eso, pero solo si llega a las personas que toman decisiones todos los días, no solo a los equipos técnicos que la construyen. De eso se trata este artículo: qué cambia cuando el negocio puede preguntarle directamente a sus datos, y cómo lo estamos viendo en la práctica con Amazon Quick, tanto en BigCheese como en clientes.
De pedir un reporte a hacer una pregunta
El cambio de fondo no es tecnológico, es de hábito. Durante años, la forma de obtener información fue pedir un reporte: alguien lo especifica, alguien lo construye, alguien lo revisa, y días después llega una respuesta que muchas veces genera una pregunta nueva. Pedimos y construimos dashboards: decenas, cientos, miles. Con info repetida, y que siempre generan una pregunta más (y otro dashboard más). Con un asistente de IA conectado a los datos de la empresa, esa cadena se reduce a una pregunta en lenguaje natural y una respuesta que dice de dónde salió.
Ese último punto es importante. Una respuesta sin fuente es una opinión; una respuesta que cita el documento, el correo o el dataset del que salió es algo sobre lo que se puede decidir. Por eso el valor no está en «tener un chat», sino en que el asistente trabaje sobre las fuentes reales de la organización (los espacios con la documentación de cada área, el correo y el calendario, los dashboards y datasets que ya existen) y respete en todo momento lo que cada persona puede ver.
Casos de uso que vemos en áreas no técnicas
Los casos que más valor generan rara vez son los más sofisticados. Son los que resuelven una fricción cotidiana que nadie había podido atacar porque no justificaba un desarrollo a medida.
Cierre de proyecto y entregables.
En una empresa de servicios, lo que se le entrega a un cliente queda repartido entre el correo de las personas del proyecto, carpetas personales, y el repositorio «oficial» del proyecto. Al cerrar un proyecto, reconstruir qué se entregó es un trabajo manual y propenso a omisiones. Hoy, el project manager y el líder técnico le piden al asistente que busque en su correo los entregables enviados al cliente en el contexto del proyecto y los contraste con lo que hay en la carpeta oficial. El resultado es una lista de faltantes para completar. Lo que antes era una tarde de búsqueda pasa a ser una consulta, y lo definimos como un prompt estándar para que todos los PMs lo hagan igual.
Estado de un proyecto sin reuniones de status.
Con un espacio que reúne la documentación del proyecto, más el correo y el calendario, las notas de la última daily, cualquier persona de la dirección puede preguntar en qué quedó la última reunión o cómo viene un hito, y recibir una respuesta con las referencias. El equipo del proyecto valida la respuesta en lugar de redactar un informe desde cero.
Seguimiento operativo.
La detección de horas no cargadas, que antes dependía de cruzar exportaciones a mano, la resuelve un agente que lee del datalake y avisa a quien corresponde. El área de operaciones deja de perseguir planillas y se concentra en las excepciones.
Adopción en una entidad financiera.
En un banco de la región, después de una demostración de casos concretos sobre sus propios procesos, el equipo interno de IA del cliente tomó la posta y definió un despliegue progresivo por áreas (operaciones, people, administración, contact center, ejecutivos y asesores, y así…). El trabajo con nosotros se ordenó en dos frentes: los casos de uso de negocio por un lado, y la administración y el gobierno de la plataforma por el otro. En un sector regulado, ese segundo frente es el que habilita al primero (y es imprescindible!).
No todo va en el asistente
Una lección que aprendimos rápido: no todos los casos de uso tienen que resolverse en el asistente. Cuando el valor está en que una persona pregunte, explore y decida (consultar, resumir, comparar, preparar), un asistente como Amazon Quick es la herramienta correcta. Cuando el caso es un proceso automático, con integraciones a sistemas transaccionales, reglas de negocio estrictas y volumen alto, conviene construir un agente a medida sobre Amazon Bedrock AgentCore.
Tener ese criterio claro desde el principio evita dos errores comunes: forzar en el asistente un proceso que necesita una integración robusta, o construir a medida algo que el negocio podría haber resuelto solo en una tarde. Este tipo de definición es la que sale de los AI Assessments que les contaba en otro post.
Adoptar sin perder el control
Darle IA al negocio no significa abrir todo. La adopción funciona cuando el asistente entra por la misma puerta que el resto de las herramientas: la identidad corporativa, espacios organizados por área y permisos que se derivan de los grupos que ya existen. Así, cada persona ve solo lo que ya podía ver, y el equipo de seguridad gobierna la IA con el mismo modelo con el que gobierna todo lo demás. Desarrollamos ese enfoque en detalle en Gobernar la IA antes de escalarla.
Cómo empezar
Lo que vemos funcionar es lo mismo que recomendamos para cualquier iniciativa de IA: pensar en grande y empezar por algo alcanzable.
- Un área y pocos casos, con valor claro. Mejor tres casos que la gente usa todos los días que veinte que nadie recuerda. En los clientes que mejor arrancaron, el despliegue empezó con un grupo acotado de usuarios y se amplió a partir de lo que esos primeros usuarios lograron.
- Capacitación pensada para áreas no técnicas. La herramienta no se adopta sola. Un catálogo corto de sesiones por área, con casos de esa área, mueve más la aguja que una capacitación genérica. Y conviene identificar champions que sostengan el uso dentro de cada equipo.
- Medir el uso y el valor. Cuántas personas lo usan, para qué y cuánto tiempo ahorran. Es la base para decidir si escalar, y conecta directamente con la lógica de construir el caso de negocio antes de invertir.
- Estandarizar lo que funciona. Cuando un caso demuestra valor, se convierte en un prompt, un espacio o un agente compartido, para que no dependa de quién lo descubrió.
El punto
La IA genera más valor cuando la usa quien toma las decisiones, no solo quien la construye. Los equipos técnicos van a seguir construyendo agentes y plataformas, pero el salto de productividad más grande está en que comercial, operaciones y la dirección puedan responder sus propias preguntas, con fuentes y con los mismos controles de siempre, sin depender de la construcción (o construyendo ellos!).
El desafío no es la tecnología: es cambiar el hábito de pedir por el hábito de preguntar.
Sebastián Grattarola
CTO de BigCheese, premier partner de AWS. Ayudo a fintechs, retails y empresas de pagos de LATAM a construir en AWS con gobierno, seguridad y escala.