Innovación Accesible

Evaluar sistemas autónomos modernos exige mirar mucho más allá del resultado final que presentan a los usuarios. Aunque una tarea se resuelva de manera aparentemente correcta, el proceso interno puede haber estado lleno de irregularidades, consultas excesivas o decisiones cuestionables. Cuando un agente decide qué herramientas utilizar y cómo navegar por un flujo de trabajo, la calidad de su desempeño no se define únicamente por el acierto superficial. Un enfoque de evaluación riguroso debe examinar la trayectoria completa, las herramientas consultadas, el cumplimiento de los permisos asignados, las verificaciones realizadas, el costo operativo y las condiciones bajo las cuales el sistema decidió detenerse o escalar el caso a revisión humana. Observar solo la respuesta final oculta riesgos operativos significativos y puede generar una falsa sensación de seguridad sobre la robustez de la tecnología empleada. Para entender esta diferencia, imaginemos un caso hipotético en el que dos ejec...

Un agente de IA puede decidir qué herramienta utilizar o qué paso dar a continuación. Sin embargo, esa capacidad no implica que deba tener libertad ilimitada. La arquitectura debe establecer qué herramientas puede utilizar, qué datos puede consultar, cuánto tiempo o cuántas llamadas puede consumir y en qué situaciones debe detenerse. Estos límites permiten contener errores y costos. Un asistente de soporte, por ejemplo, puede consultar documentación y elaborar una recomendación. Si la solicitud exige modificar permisos o ejecutar una acción sensible, la autorización debe comprobarse mediante reglas y controles independientes del modelo. También importa definir qué sucede cuando el agente no logra resolver el caso. Repetir indefinidamente una consulta no mejora necesariamente el resultado; puede incrementar costo y latencia. Una condición de detención y un mecanismo de escalamiento forman parte de una solución confiable. La pregunta de diseño no es cuánta autonomía podemos darle, sino c...

¿Cuándo necesita realmente un agente de inteligencia artificial? La respuesta no depende de cuántos pasos tenga un proceso, sino de cuánto necesita decidir durante su ejecución. Un workflow es una secuencia de actividades y condiciones previamente definidas. Puede incorporar un modelo de lenguaje para clasificar un correo, extraer información o redactar una respuesta, sin convertirse por ello en un agente. El recorrido sigue determinado por reglas, validaciones y transiciones que el diseñador conoce de antemano. Un agente, en cambio, puede decidir qué herramienta utilizar, qué información consultar o cuál será el siguiente paso a partir de los resultados que obtiene. Esa flexibilidad puede ser útil, pero también introduce incertidumbre: hay que controlar sus permisos, limitar los intentos y observar qué decisiones tomó. Pensemos en un sistema que recibe facturas por correo. Si siempre debe descargar el adjunto, extraer datos, validar campos y registrar el resultado, un workflow suele s...

Automatizar no significa eliminar siempre a la persona del proceso. En sistemas con IA, la intervención humana puede funcionar como un control deliberado cuando una decisión tiene suficiente riesgo, incertidumbre o impacto. El punto importante es elegir dónde colocar ese control. Pedir aprobación para cada paso aumenta latencia y carga operativa; no pedirla nunca puede permitir que un error probabilístico produzca consecuencias difíciles de revertir. Una arquitectura human-in-the-loop define criterios explícitos. Impacto, reversibilidad, confianza, permisos y costo del error pueden determinar si una acción continúa automáticamente, solicita aprobación o se detiene. Las tareas rutinarias y verificables pueden conservar autonomía. Las acciones sensibles, ambiguas o de alto impacto requieren un nivel de supervisión proporcional al riesgo. El objetivo no es mantener a una persona dentro de todos los flujos, sino utilizar su intervención donde realmente aumenta la confiabilidad del sistema.

Fine-tuning puede ser una herramienta valiosa, pero no debería utilizarse como respuesta automática cuando un modelo no produce exactamente el comportamiento esperado. La primera pregunta es qué tipo de problema se intenta resolver. Si la información cambia con frecuencia, una base de datos o una API suele ser la fuente adecuada. Si el conocimiento está en documentos que deben mantenerse actualizados, RAG permite recuperarlo sin volver a entrenar. Si el requisito puede expresarse de forma explícita, reglas o prompting suelen ser alternativas más simples. Fine-tuning modifica patrones aprendidos a partir de ejemplos. Puede resultar útil para comportamientos repetibles, estilos de salida o tareas especializadas cuando las técnicas más sencillas no alcanzan la calidad necesaria. Sin embargo, ajustar un modelo introduce trabajo adicional: preparar datos, evaluar resultados, mantener versiones y comprobar que la mejora compensa el costo. La decisión profesional no consiste en preguntar si e...

Utilizar siempre el modelo más potente puede simplificar una arquitectura, pero también aumentar costo y latencia sin mejorar de forma relevante las tareas sencillas. El model routing permite asignar distintos modelos según las características de cada solicitud. Una clasificación rutinaria puede resolverse con una opción rápida y económica, mientras un caso ambiguo, complejo o de mayor riesgo puede escalarse a un modelo más capaz. La decisión no debería basarse únicamente en precio. También importan precisión, latencia, privacidad, disponibilidad y el costo operativo de corregir errores. Un modelo barato que genera más revisiones puede resultar más caro en el proceso completo. El router tampoco necesita utilizar IA. Muchas veces reglas simples —tipo de tarea, origen, nivel de riesgo o tamaño del contexto— son más fáciles de explicar y mantener. El objetivo no es utilizar muchos modelos, sino asignar capacidad de forma justificable y medir si la complejidad adicional realmente produce b...

Los modelos de IA son útiles para interpretar información no estructurada, pero la extracción y la validación resuelven problemas distintos. Un modelo puede identificar correctamente la estructura esperada y aun así devolver un monto, una fecha o una categoría incorrectos. Por eso, el resultado no debería pasar directamente a una operación de negocio. Una arquitectura más confiable separa responsabilidades. La IA interpreta; después, reglas determinísticas comprueban formatos, campos obligatorios, rangos, catálogos y otras condiciones que puedan verificarse sin ambigüedad. Cuando una validación falla, el sistema puede solicitar corrección, enviar el caso a revisión o detener la operación según el riesgo. No es necesario pedirle al mismo modelo que confirme su propia respuesta como única defensa. La combinación de interpretación probabilística y controles determinísticos permite aprovechar la flexibilidad de la IA sin delegarle decisiones que pueden verificarse de forma más confiable.

Los sistemas con IA suelen procesar contenido que no controlamos: correos, documentos, páginas web, mensajes o información recuperada mediante RAG. Ese contenido puede incluir instrucciones dirigidas al modelo y tratar de modificar su comportamiento. La defensa fundamental consiste en separar información de autoridad. Un documento puede aportar datos para responder una consulta, pero no debe adquirir permisos para cambiar reglas, ejecutar acciones o ampliar privilegios. Por ejemplo, un correo podría indicar que se ignore una política y se modifique un registro administrativo. El modelo puede analizar o resumir ese texto, pero la operación debe seguir dependiendo de permisos, reglas de negocio y, cuando corresponda, confirmación humana. Esto implica que la seguridad no puede descansar únicamente en un prompt que diga “ignore instrucciones maliciosas”. Las fronteras importantes deben implementarse fuera del modelo. La IA puede interpretar contenido no confiable. Lo que no debe hacer es p...

Los fallos forman parte de cualquier automatización que dependa de APIs, modelos o servicios externos. La diferencia entre un flujo frágil y uno resiliente está en cómo responde cuando algo deja de funcionar. Un reintento puede ser adecuado ante un error temporal, pero no ante datos inválidos o una operación cuyo resultado quedó incierto. En esos casos, repetir a ciegas puede aumentar costos, saturar el servicio o producir duplicados. También existen otras respuestas: utilizar un fallback seguro, degradar temporalmente una función o detener el proceso y solicitar revisión. La decisión debe proteger primero la consistencia del negocio. Un punto especialmente delicado ocurre cuando un sistema externo pudo completar una escritura antes de devolver un timeout. La recuperación requiere idempotencia, verificación o reconciliación antes de ejecutar nuevamente. La resiliencia no consiste en insistir hasta que algo funcione. Consiste en diseñar respuestas controladas para cada tipo de fallo.

Una automatización con IA puede entregar un resultado correcto y aun así ser difícil de operar. Cuando aparece un fallo, conocer únicamente que “algo salió mal” no permite determinar qué etapa falló, qué modelo intervino o si el problema fue de datos, integración o lógica. La observabilidad convierte la ejecución en evidencia. Registros estructurados, métricas y trazas permiten seguir cada trabajo, medir latencia y errores, y relacionar una decisión con el contexto técnico que la produjo. Esto resulta especialmente importante en procesos de varios pasos. Un identificador de trabajo puede conectar la recepción de un documento, su extracción, las validaciones y la escritura final sin depender de revisar sistemas aislados. Sin embargo, observar no significa guardar todo. Los registros deben limitar datos sensibles, definir retención y capturar únicamente información útil para operar y mejorar el sistema. Una solución confiable no solo produce resultados: también permite explicar qué ocurr...