El cementerio de herramientas de IA internas es grande y sigue creciendo. Un desarrollador construye un bot de Slack que resume notas de reuniones. Funciona. Durante dos semanas, todos lo usan. Luego empieza a resumir incorrectamente en reuniones largas, nadie lo arregla, y el equipo silenciosamente vuelve a leer las notas por su cuenta.
Este patrón se repite porque construir una herramienta de IA interna y construir una que la gente realmente adopte son problemas diferentes. La parte técnica suele ser la más pequeña.
Las herramientas internas con las tasas de adopción más altas resuelven un problema del que una persona específica se queja en voz alta. No "podríamos usar IA para mejorar X" sino "María pasa cuatro horas cada viernes compilando el reporte de estado semanal y lo odia." María es la víctima identificada. Construye para María.
Las víctimas sin nombre producen herramientas sin usar. "El equipo podría ahorrar tiempo con revisión de código asistida por IA" falla porque nadie es dueño del problema. Cuando la herramienta tiene bordes ásperos, nadie aboga por arreglarlos. Muere silenciosamente.
La forma más rápida de construir una herramienta interna que nadie use es diseñarla de forma aislada y lanzarla como un producto terminado. El equipo no la pidió, el flujo de trabajo que asume no coincide con cómo la gente realmente trabaja, y cuando llegan los comentarios, el constructor ya se ha movido al siguiente proyecto.
Construye la primera versión en una semana. Debe ser tosca. Dásela a la víctima identificada antes de que esté pulida. Obsérvala usarla. Las cosas que hacen que no esperabas son más valiosas que cualquier función que planificaste.
Las herramientas de IA internas fallan silenciosamente. Una herramienta de resumen que produce resúmenes plausibles pero inexactos es peor que ninguna herramienta de resumen —el equipo toma decisiones basadas en información incorrecta sin darse cuenta. Una revisión de código asistida por IA que omite errores reales mientras señala problemas de estilo entrena a los ingenieros a ignorar las alertas.
Cada herramienta de IA interna necesita una capa de evaluación antes de tocar trabajo real. No tiene que ser compleja. Para una herramienta de resumen, toma 20 documentos reales, haz que un humano produzca los resúmenes correctos, y mide la precisión en relación con ellos. Para una herramienta de revisión de código, recopila tasas de falsos positivos y falsos negativos del primer mes de uso en producción. Sin esto, estás volando a ciegas.
El comportamiento del LLM cambia cuando los modelos se actualizan. El prompt que funcionaba en la versión N del modelo puede producir salidas diferentes en la versión N+1. Sin un conjunto de pruebas y un propietario que supervise la herramienta, las actualizaciones de modelos rompen las herramientas internas silenciosamente.
Nombra un propietario antes del lanzamiento. No solo la persona que la construyó —la persona responsable de que funcione correctamente en tres meses. Si no puedes nombrar a esa persona, la herramienta estará sin mantenimiento en un trimestre.
Las herramientas internas con mejor adopción siguen el mismo patrón de lanzamiento: un usuario durante dos semanas, cinco usuarios durante dos semanas, todo el equipo. Cada fase expone una clase diferente de problema. La fase de un usuario expone desajustes fundamentales de flujo de trabajo. La fase de cinco usuarios expone casos extremos. El lanzamiento a todo el equipo expone problemas de escala y fiabilidad.
Saltarse al lanzamiento a todo el equipo porque la demo se veía bien es el error más común. La demo fue construida contra entradas controladas. Los usuarios en producción tienen entradas sorprendentes.
Una herramienta de IA interna exitosa es usada diariamente, sin recordatorios, por las personas para las que fue construida. El uso es visible en logs o analíticas. Cuando la herramienta tiene un problema, alguien lo reporta y se arregla. Si ninguna de esas tres cosas es cierta después de 90 días, la herramienta no es exitosa independientemente de qué tan buena sea la implementación técnica.
Construye para la adopción, no para la finalización.
%20(1)-2.svg)
