5 errores al lanzar tu primera herramienta IA interna para PyMEs en LatAm

TL;DR

Lanzamos una herramienta IA interna sin los controles básicos y pagamos el precio: costos disparados, datos de clientes expuestos en logs y ninguna forma de dar marcha atrás. Estos son los 5 anti-patrones que debes evitar antes de tu próximo despliegue.

El día que nos dimos cuenta de que habíamos fallado

Eran las 11 de la noche cuando uno de los desarrolladores del equipo me escribió por Slack: “Oye, acabo de ver un nombre completo y un RUT de cliente impreso en los logs de producción.” Llevábamos 3 semanas con la herramienta IA activa para las 30 personas del equipo. Hasta ese momento, todos pensaban que iba “bastante bien”.

No iba bien.

Lo que sigue es el recuento honesto de los 5 errores que cometimos. No son errores de código. Son errores de criterio, del tipo que comete cualquier equipo de una PyME en LatAm que mueve rápido sin parar a pensar en los bordes. Si tu empresa tiene entre 10 y 200 empleados y está en México, Colombia, Chile, Argentina o cualquier otro país de América Latina, este artículo es para ti. Los recursos suelen ser ajustados, los equipos técnicos son pequeños y la presión por mostrar resultados con IA es real. Eso hace que estos errores sean incluso más probables, y sus consecuencias más difíciles de absorber.

Error 1: Lanzamos la herramienta IA interna sin una sola eval automatizada

Construimos el flujo, lo probamos manualmente con 10 o 15 prompts y dijimos “funciona.” Eso no es testing, es esperanza.

Un conjunto de evals es el grupo de casos de prueba que se ejecutan automáticamente cada vez que cambias el prompt, el modelo o el contexto del sistema. Sin eso, no tienes forma de saber si un ajuste que hiciste el martes rompió algo el miércoles.

En nuestro caso, cambiamos el modelo base de GPT-4o a una versión con menor latencia. Las respuestas se veían correctas en los primeros 5 ejemplos. En el caso de uso número 23, el modelo empezó a truncar respuestas largas de forma silenciosa. Lo descubrimos 11 días después, cuando un usuario reportó que la herramienta “ya no sirve para resúmenes largos.”

La solución no es complicada: arma al menos 20 casos de prueba representativos, con entrada y salida esperada, y córrelos antes de cada despliegue. Herramientas como Braintrust o incluso un script de Python con asserts básicos sirven para empezar. Para una PyME en LatAm que no tiene un equipo de QA dedicado, este conjunto de evals es la red de seguridad mínima aceptable. El tiempo de armarlo es de 2 a 4 horas la primera vez. El tiempo de diagnosticar un fallo silencioso sin evals puede ser de días, con usuarios afectados todo ese tiempo.

Para construir un buen conjunto de evals desde cero, considera estas categorías de casos de prueba: respuestas correctas en el caso típico, comportamiento en inputs vacíos o malformados, manejo de idiomas mixtos (muy común en equipos LatAm que mezclan español e inglés), respuestas cuando el contexto del sistema es ambiguo, y límites de longitud de entrada y salida. Con 5 casos por categoría ya tienes una base sólida de 25 pruebas que detectan la mayoría de las regresiones comunes.

Error 2: No teníamos plan de rollback para nuestra herramienta IA interna

Cuando encontramos el problema de truncación, la pregunta obvia fue: “¿Cómo volvemos a la versión anterior?” Nadie sabía la respuesta exacta.

Teníamos el prompt en un archivo de texto en el repositorio, pero no había un procedimiento documentado. ¿Quién ejecuta el rollback? ¿En qué rama está la versión anterior? ¿Cómo se notifica al equipo que estamos en modo fallback?

Tardamos 4 horas en restaurar algo que debería haber tomado 10 minutos. Un plan de rollback no es un documento largo: es una tarjeta de referencia rápida con el comando exacto, el responsable y el canal de comunicación. Escríbela antes del lanzamiento, no después del primer incidente.

En el contexto de una PyME latinoamericana, el plan de rollback tiene una dimensión adicional: muchas veces el equipo técnico es una sola persona o un equipo muy pequeño. Si esa persona está de vacaciones o enferma cuando ocurre el incidente, nadie más sabe qué hacer. El plan de rollback debe ser ejecutable por alguien con conocimientos técnicos básicos, no solo por el arquitecto del sistema.

Un formato que funciona bien es una tarjeta con cuatro campos: el comando o pasos exactos para revertir, el nombre del responsable primario y del responsable secundario, el canal donde se anuncia el incidente (por ejemplo, un canal de Slack llamado “incidentes-ia”), y el criterio para saber cuándo el rollback fue exitoso. Esa tarjeta debería estar en el repositorio, en Notion, en Confluence, en cualquier herramienta de documentación que uses, y debería actualizarse cada vez que cambia la arquitectura del sistema.

Error 3: PII viajando limpia por los logs

Este fue el más serio. Nuestra herramienta procesaba consultas de soporte que los agentes copiaban directamente desde los tickets. Esos tickets contenían nombres, correos y, en algunos casos, números de identificación fiscal.

El problema no era que guardáramos esa información. El problema era que la guardábamos sin saberlo, en texto plano, en los logs de producción de un proveedor de infraestructura que no era nuestro procesador de datos contractual.

La solución que aplicamos después: un paso de scrubbing automático con Microsoft Presidio antes de que cualquier texto llegue al log. Presidio detecta entidades como emails, números de teléfono y documentos de identidad, y las reemplaza por tokens. El pipeline de logging nunca ve el dato real.

Si procesas cualquier tipo de información de clientes, este paso no es opcional. En México, Colombia, Argentina y España hay marcos regulatorios (LFPDPPP, Ley 1581, PDPA, LOPD-GDD) que hacen que una fuga así tenga consecuencias reales, que incluyen multas, notificaciones obligatorias a los titulares de los datos y, en algunos casos, responsabilidad penal para los administradores. Para una PyME en LatAm, una multa bajo cualquiera de estos marcos puede ser suficiente para cerrar el negocio.

Más allá del scrubbing en los logs, hay otras tres capas que debes revisar: primero, los prompts que envías al proveedor de LLM (¿contienen PII de clientes?); segundo, las respuestas que recibes del modelo (¿podrían incluir datos que el modelo memorizó de alguna forma?); tercero, cualquier base de datos de contexto o historial de conversaciones que uses para personalizar las respuestas. Un audit de flujo de datos de 2 horas antes del lanzamiento puede identificar todos estos vectores. Es tiempo bien invertido.

Error 4: La herramienta IA interna sin tope de costo en la API

En la semana 2, uno de los usuarios encontró un caso de uso que no habíamos anticipado: empezó a usar la herramienta para procesar documentos de 40 páginas, uno tras otro, durante horas. Completamente legítimo desde su perspectiva. Desde la perspectiva de la factura, fue un susto.

Ese día gastamos 8 veces lo que esperábamos gastar en todo el mes. No había ningún hard cap configurado en la cuenta del proveedor de LLM.

Todos los proveedores principales, OpenAI, Anthropic, Google, permiten configurar límites de gasto mensual y alertas por umbral. Configúralos antes del primer día de uso real. El número exacto depende de tu presupuesto, pero el principio es simple: el límite máximo que estás dispuesto a gastar en un mes debe vivir en la configuración de la cuenta, no en la esperanza de que nadie abuse del sistema.

Un límite razonable para un equipo de 30 personas en una herramienta interna de uso moderado suele estar entre $150 y $400 al mes. Pon la alerta al 70% del límite para tener tiempo de reaccionar.

Para PyMEs en LatAm, este punto tiene un matiz importante: el tipo de cambio. Si tu empresa opera en pesos mexicanos, pesos colombianos, pesos argentinos o cualquier otra moneda local, un pico de costos en dólares puede tener un impacto desproporcionado en tu flujo de caja. La regla del hard cap es aún más crítica cuando tu moneda funcional no es el dólar.

Además del límite global mensual, considera implementar límites por usuario o por caso de uso dentro de tu aplicación. Puedes hacerlo con un contador simple en tu base de datos que verifique cuántos tokens ha consumido un usuario en el día o en el mes antes de procesar su siguiente solicitud. Esta capa de control dentro de la app complementa el hard cap del proveedor y te da visibilidad granular de qué usuarios o flujos están consumiendo más recursos.

Error 5: Cero humano en el loop para decisiones que importan

Este error es más sutil, pero potencialmente el más costoso. Construimos la herramienta para que fuera fluida: el usuario pregunta, el modelo responde, la acción se ejecuta. Sin fricción.

El problema es que “sin fricción” en el contexto equivocado significa “sin oportunidad de corrección.” Uno de los flujos permitía que la herramienta redactara y enviara correos de seguimiento a clientes de forma directa. Era rápido, los usuarios lo adoraban.

Hasta que el modelo mal interpretó el contexto de un ticket, redactó un mensaje confuso y lo envió a 14 clientes activos antes de que alguien lo notara. El daño fue manejable, pero evitable.

Para cualquier acción irreversible, el flujo correcto es: el modelo propone, el humano aprueba, el sistema ejecuta. Agregar un paso de confirmación de 3 segundos en acciones de alto impacto no arruina la experiencia. Sí evita que un correo mal redactado llegue a tus clientes.

La regla práctica que usamos ahora: si el costo de deshacer la acción supera 15 minutos de trabajo humano, hay una pantalla de confirmación con el output del modelo visible antes de ejecutar.

En el contexto de PyMEs en LatAm, el error de “cero humano en el loop” tiene otra dimensión que vale la pena mencionar: la confianza del equipo en la herramienta. Cuando un sistema automatizado comete un error visible, los empleados pierden confianza en él y empiezan a evitarlo o a desconfiar de cada output. Recuperar esa confianza puede tomar semanas. Un checkpoint de aprobación no es solo un control de seguridad; es también una señal para el equipo de que el sistema no actúa de forma completamente autónoma en situaciones que importan. Esa transparencia genera adopción más sostenible a largo plazo.

Algunos ejemplos concretos de acciones que siempre deben pasar por aprobación humana en una herramienta IA interna para PyMEs: envío de comunicaciones a clientes (correos, mensajes de WhatsApp, notificaciones push), modificaciones en registros de CRM o ERP, generación y envío de documentos con valor legal (cotizaciones, contratos, facturas), y cualquier acción que afecte configuraciones del sistema o permisos de usuarios.

Cómo se ve esto en la práctica: un ejemplo de flujo seguro

Para que estos cinco errores no queden solo como advertencias abstractas, vale la pena describir cómo se ve un flujo de lanzamiento correcto para una herramienta IA interna en una PyME de LatAm.

Supón que quieres lanzar una herramienta que ayuda a tu equipo de soporte a redactar respuestas a tickets de clientes. El flujo seguro se ve así:

Antes del lanzamiento, construyes un conjunto de 25 evals que cubren los tipos de tickets más comunes, los casos borde y las entradas malformadas. Defines quién ejecuta el rollback si algo falla (con un responsable primario y uno secundario). Configuras el pipeline de logging con Presidio para que ningún dato de cliente llegue a los logs. Configuras un hard cap mensual en la cuenta del proveedor de LLM y una alerta al 70% del límite. Y diseñas la interfaz para que el agente vea el borrador generado por el modelo antes de enviarlo, con un botón de “aprobar y enviar” explícito.

Durante el lanzamiento, despliega primero a 3 o 5 usuarios piloto durante una semana. Corre tus evals antes del despliegue para confirmar que todo funciona. Monitorea el consumo de tokens diariamente esa primera semana.

Después de la primera semana, revisa los logs (sin PII, gracias al scrubbing) para identificar patrones de uso inesperados. Ajusta el conjunto de evals con los casos reales que encontraste. Documenta cualquier incidente menor y actualiza el plan de rollback si es necesario. Solo después de esa semana de piloto, abre la herramienta al equipo completo.

Este proceso no requiere más de 2 a 3 días de trabajo adicional antes del lanzamiento. La diferencia entre hacerlo y no hacerlo es la diferencia entre un lanzamiento controlado y un incidente de datos a las 11 de la noche.

Checklist: evita estos 5 errores antes de tu despliegue IA

Antes de lanzar cualquier herramienta IA interna, especialmente si tu empresa es una PyME en LatAm con recursos técnicos limitados, verifica cada uno de estos puntos:

1. Conjunto de evals configurado y corriendo Tienes al menos 20 casos de prueba con entrada y salida esperada. Los evals se corren automáticamente antes de cada despliegue. Tienes un umbral de aprobación definido (por ejemplo, 90% de los casos deben pasar para proceder).

2. Plan de rollback documentado y probado Existe un documento con los pasos exactos para revertir. Hay un responsable primario y uno secundario identificados por nombre. El plan fue ejecutado al menos una vez en un ambiente de staging para confirmar que funciona.

3. Scrubbing de PII en el pipeline de logging Presidio u otra herramienta de scrubbing está activa antes de que cualquier texto llegue a los logs. Tienes una lista de los tipos de PII relevantes para tu negocio y tu región (RUT, CURP, NIT, DNI, CUIT, emails, teléfonos). Hiciste una prueba con datos sintéticos para confirmar que el scrubbing funciona.

4. Hard cap y alertas configurados en el proveedor de LLM El límite mensual está configurado en la cuenta del proveedor. La alerta está configurada al 70% del límite. Tienes un proceso definido para lo que pasa cuando se dispara la alerta (quién revisa, qué opciones existen).

5. Aprobación humana para acciones irreversibles Tienes una lista de todas las acciones que puede ejecutar la herramienta. Cada acción irreversible tiene un checkpoint de aprobación en la interfaz. El criterio para “irreversible” está documentado y el equipo lo conoce.

Si puedes marcar los 5 puntos, estás listo para lanzar. Si alguno falta, tienes trabajo que hacer antes de que los primeros usuarios toquen el sistema.

Ninguno de estos controles requiere expertise avanzado para implementarlos. Todos eran prevenibles con una revisión de 30 a 60 minutos antes del lanzamiento. El costo de no hacerlo, medido en tiempo de recuperación, confianza del equipo, riesgo regulatorio y facturas inesperadas, es siempre mayor que el costo de la prevención.

¿Necesitas ayuda para construir esto?

Kreante acompaña a PyMEs y founders en LatAm que quieren reemplazar SaaS caro con IA personalizada. Hemos shipped 265 proyectos (60% LowCode/AI, 70% B2B) en US, Europa y LatAm.

Agenda una llamada de 30 minutos con Kreante