Las aptitudes poco nombradas que hacen útil a un IA Engineer
La ingeniería de IA exige más que modelos y prompts: evals, observabilidad, contexto, herramientas, permisos, RAG, memoria, coste y workflows reales.
Las aptitudes poco nombradas que hacen útil a un IA Engineer
Durante los últimos años gran parte de lo que se dice sobre la Inteligencia Artificial se ha concentrado en modelos, prompts, benchmarks y lanzamientos de nuevas herramientas. Todo eso es importante pero describe solo una parte del trabajo que tenemos por delante.
En la práctica, el IA Engineer que aporta valor sostenido trabaja en una zona más operativa: convierte las capacidades probabilísticas de los LLM en sistemas útiles dentro de flujos de trabajo reales.
Ese cambio aparece en los datos del sector. En una encuesta de LangChain a más de 1.300 profesionales, el 57,3% de las organizaciones declaraba tener agentes en producción. La misma encuesta indicaba que el 89% había implementado alguna forma de observabilidad para agentes, el 52,4% ejecutaba evaluaciones offline sobre conjuntos de prueba.
La distancia entre observabilidad y evaluación muestra que los equipos ya pueden mirar qué ocurre pero todavía están madurando la forma de medir si el sistema trabaja bien.
Ahí emerge una definición práctica del IA Engineer contemporáneo: una persona capaz de diseñar el recorrido completo entre una intención humana, un modelo, unas herramientas, unos datos, unos controles y una salida verificable.
Su trabajo debe combinar ingeniería de software, criterio de producto, diseño de evaluación, seguridad aplicada y comprensión de operaciones.
Las aptitudes más importantes en este perfil reciben nombres poco vistosos para linkedin: trazabilidad, contexto, contratos, permisos, latencia, regresión, criterio de automatización, taxonomía de fallos. Son palabras menos llamativas que “agentes autónomos” o “razonamiento avanzado”, pero es lo que sostiene la diferencia entre una demo convincente y un sistema que merece entrar en producción con riesgos acotados.
1. Diseñar evaluaciones útiles
La experiencia me muestra que la evaluación debe ser la aptitud central de IAE.
El rol de IA Engineer necesita diseñar maneras de saber si el sistema cumple con su función. Si mejora con los cambios y si mantiene su calidad cuando cambia el modelo, el prompt, la herramienta o los datos.
Las buenas evaluaciones empiezan con casos reales: conversaciones de usuarios, solicitudes internas, documentos ambiguos o excepciones que ya han ocurrido entre otros. A partir de ese material, el IAE puede definir ejemplos de referencia, criterios de aceptación y pruebas de regresión.
Las evaluaciones ordenan la comunicación entre producto, negocio e ingeniería.
Un equipo puede discutir durante horas sobre si una respuesta “parece buena”. Sin embargo, una suite de evaluación convierte esa discusión en ejemplos concretos: este caso debe extraer tres campos, este otro debe pedir confirmación, este otro debe abstenerse, este otro debe ejecutar una herramienta con parámetros precisos.
Anthropic describe una práctica ya habitual en agentes de producción: combinar evaluadores basados en código, evaluadores basados en modelos y revisión humana.
Los evaluadores de código sirven para condiciones objetivas; los evaluadores con modelos ayudan en tareas abiertas; la revisión humana calibra criterios cuando hace falta juicio experto.
Esta aptitud de evaluador requiere una visión de ingeniería: elegir qué merece ser evaluado. Medir todo va a producir ruido. Medir solo la respuesta final dejará fuera errores importantes. Un buen IAE evalúa resultado, proceso y coste operativo. Observa si el agente usó la herramienta adecuada, si respetó permisos, si consumió demasiados tokens, si tardó demasiado, si pidió confirmación en el momento correcto y si dejó una traza comprensible.
La evaluación útil permite cambiar de modelo con seguridad, ajustar prompts con criterio, detectar regresiones y priorizar mejoras según impacto.
2. Construir taxonomías de fallos
Cuando los sistemas basados en IA fallan, el primer impulso naif suele ser tocar el prompt. Esa reacción puede producir mejoras puntuales y también deuda técnica. El rol de un IAE eficaz consiste en clasificar los fallos antes de intervenir.
Una buena taxonomía de fallos permite discriminar causas: recuperación deficiente de documentos, contexto excesivo, instrucciones ambiguas, herramienta mal definida, datos obsoletos, latencia alta, permisos demasiado amplios, falta de confirmación humana, criterio de abstención débil o salidas mal estructuradas.
Cada categoría conduce a una intervenciones distintas: un fallo de recuperación exige revisar ingesta, chunking, metadatos o ranking. Un fallo de herramienta exige ajustar schemas, validaciones o errores esperados. Un fallo de incertidumbre exige mejorar umbrales, preguntas de control o criterios de abstención. Un fallo de UX exige cambiar el flujo.
Esta capacidad de identificar fallos reduce el azar en la mejora del sistema. Cada error se convierte en un dato clasificado, vinculado a una causa y asociado a una acción.
Para mí, esta forma de trabajar resume una idea básica de anemonautas: la claridad empieza observando. Cuando automatizamos una tarea, necesitamos entender cómo falla hoy, cuánto cuesta cada fallo y qué parte del proceso merece priorizar la intervención.
3. Gestionar el contexto con criterio
La gestión de contexto se ha convertido en una disciplina propia. Los modelos aceptan cada vez más información y más formatos. El valor aparece cuando ese contexto está seleccionado, ordenado y actualizado.
Un IAE necesita decidir qué entrará en la ventana de contexto: qué queda fuera, qué se resume, qué se recupera bajo demanda y qué se convierte en instrucción estable.
También sabe separar fuentes: instrucciones del sistema, preferencias del usuario, datos externos, memoria, documentos recuperados, resultados de herramientas y estado temporal del flujo.
Cada entrada vive en un lugar distinto.
La calidad del contexto siempre afecta a la calidad del resultado. Un documento correcto situado tras varios fragmentos irrelevantes puede perder influencia. Un fragmento externo puede intentar introducir instrucciones que alteren el comportamiento del agente. Un resumen demasiado agresivo puede eliminar la condición que hacía único el caso.
Gestionar contexto implica también saber diseñar jerarquías. Algunas informaciones son reglas, otras son evidencia, otras son hipótesis. Convertir esa mezcla en una estructura manejable forma parte del rol del IAE.
4. Diseñar contratos para herramientas
Los agentes conectados a herramientas amplían el campo de trabajo del modelo. La IA ya puede consultar bases de datos, leer documentos, escribir emails, crear tickets, ejecutar código, actualizar un CRM o llamar a APIs internas. Esa potencia requiere contratos precisos.
En ingeniería de IA, como en ingeniería de software, un contrato define qué puede hacer la herramienta, qué argumentos acepta, los permisos que necesita, los errores que devuelve, sus límites, los datos que quedan registrados o qué confirmaciones hacen falta. La herramienta pasa de ser una función suelta a una unidad de responsabilidad.
OpenAI documenta que su Agents SDK traza generaciones del modelo, llamadas a herramientas, handoffs, guardrails y eventos personalizados durante una ejecución. Esa estructura refleja cómo los agentes modernos operan como workflows observables, con pasos internos que conviene inspeccionar durante desarrollo y producción. ([OpenAI GitHub][3])
El contrato de herramienta también tiene una dimensión de producto. Una acción de lectura, una acción de escritura y una acción irreversible requieren tratamientos distintos. Leer una factura, crear un borrador y enviar un pago conllevan niveles de riesgo diferentes. El rol del IAE consiste en traducir esa diferencia en permisos, validaciones y confirmaciones.
Diseñar una buena herramienta limita su ambigüedad. Los parámetros son explícitos. Sus nombres describen acciones reales. Sus errores ayudan al agente a recuperarse. Sus resultados devuelven la información necesaria para el siguiente paso y su diseño protege al sistema de ejecuciones excesivas, silenciosas o difíciles de explicar.
5. Diseñar permisos y alcance de acción
La autonomía tiene valor cuando está bien acotada. Para eso se necesitan límites operativos: qué puede hacer el sistema por sí mismo, qué debe proponer, qué debe pedir, qué debe registrar y qué debe escalar a una persona.
Esta aptitud se expresa en el alcance de acción. Un agente debe tener permisos explícitos para buscar información, preparar respuestas, sugerir una clasificación, crear un borrador o ejecutar una acción final. Cada nivel implica un riesgo distinto. El diseño responsable asigna el nivel mínimo suficiente para cada tarea.
La seguridad frente a prompt injection refuerza esta necesidad. OpenAI define el prompt injection como instrucciones situadas en contenido externo que intentan llevar al modelo hacia acciones distintas de la intención del usuario. En agentes con navegación, lectura de documentos o acciones sobre herramientas, la defensa requiere controles que limiten el impacto de una manipulación exitosa. ([OpenAI][4])
La seguridad práctica se diseña por capas. El contenido externo se trata como dato. Las acciones sensibles pasan por confirmación. Los datos privados tienen restricciones de transmisión. Las herramientas reciben scopes concretos. Las rutas de salida están controladas.
OpenAI también describe un enfoque basado en fuente y destino: el riesgo aparece cuando una fuente influenciable se combina con una capacidad peligrosa, como transmitir información a terceros, seguir un enlace o interactuar con una herramienta. Esa lectura resulta útil para diseñar permisos en sistemas internos. ([OpenAI][4])
Los IAE aportan valor operativo directo con esta capacidad. Un sistema con límites claros genera confianza. Un sistema con permisos amplios exige vigilancia constante.
6. Curar datos para RAG
Muchas implementaciones de RAG se tratan como un problema de embeddings y base vectorial. Esa es la parte tutorial.
En producción, el trabajo decisivo suele estar antes: calidad documental, estructura, permisos, frescura, duplicados, fragmentación y metadatos. Un IAE aprende a mirar los datos como material operativo. Qué documentos representan conocimiento vigente. Qué versiones conviven. Qué campos permiten filtrar. Qué permisos hereda cada fragmento. Qué contenido contiene instrucciones, ejemplos, tablas, anexos o imágenes. Qué fuentes tienen autoridad cuando dos documentos discrepan.
La curación de datos requiere trabajo poco visible: normalizar títulos, eliminar duplicados, separar anexos, marcar fechas de vigencia, crear metadatos útiles, mantener vínculos con fuentes originales, diseñar chunking según el tipo de documento, combinar búsqueda semántica con filtros deterministas y evaluar la recuperación con preguntas reales.
Del IAE se espera criterio al conectar recuperación y tarea. Un asistente legal interno necesita trazabilidad por cláusula. Un agente comercial necesitará actualidad y tono. Un sistema de soporte necesitará correspondencia con políticas vigentes. Un copiloto de operaciones necesitará distinguir procedimiento oficial, práctica habitual y excepción aprobada.
La calidad de un RAG se mide en el comportamiento final. Recuperar documentos parecidos aporta poco si el sistema usa una versión vencida, ignora permisos o mezcla fuentes de autoridad distinta. La aptitud consiste en convertir documentación dispersa en una base consultable con reglas claras.
7. Diseñar memoria como producto
La memoria en sistemas de IA mezcla criterios de producto, ingeniería y gobernanza. Guardar información de una conversación puede mejorar continuidad, y cada dato persistente introduce responsabilidad.
Hay que distinguir preferencias, hechos, inferencias, decisiones, permisos y datos sensibles. Estas categorías merecen tratamientos distintos. Una preferencia de formato puede mantenerse durante meses. Un estado de proyecto puede caducar. Una inferencia sobre una persona necesita trazabilidad y posibilidad de corrección. Un dato sensible requiere controles estrictos.
La memoria útil tiene fuente, fecha, alcance y mecanismo de actualización. También tiene una forma de ser revisada. Un usuario debe poder corregir una preferencia mal capturada. Un equipo debe poder auditar qué información se usa para personalizar respuestas. Un sistema debe poder retirar datos vencidos.
Esta aptitud aparece especialmente en productos internos. Los equipos quieren asistentes que recuerden contexto de proyectos, clientes, decisiones y procedimientos. Ese recuerdo aporta valor cuando respeta límites claros. La memoria bien diseñada reduce repetición. La memoria mal estructurada acumula ruido.
El IA Engineer diseña memoria con preguntas operativas: qué mejora al conservarse, qué riesgo añade, quién puede verlo, durante cuánto tiempo sigue siendo válido, cómo se corrige y cómo se elimina.
8. Gestionar coste y latencia como parte de la calidad
La calidad de un sistema de IA incluye tiempo de respuesta y coste por tarea. Un resultado correcto que llega tarde puede fallar en el flujo real. Una automatización cara puede destruir su propio caso de negocio.
El IA Engineer necesita medir tokens, llamadas a modelos, número de pasos, uso de herramientas, caché, streaming, retries, timeouts y coste por unidad de trabajo. También necesita elegir el modelo suficiente para cada paso. Algunas tareas requieren modelos fuertes. Otras pueden resolverse con clasificadores, reglas, modelos pequeños o llamadas estructuradas.
El routing de modelos se convierte así en una aptitud práctica. Un flujo puede usar un modelo rápido para clasificar intención, otro más capaz para resolver casos complejos, un verificador para salidas sensibles y una ruta determinista para tareas repetibles. Esta arquitectura reduce coste y mejora experiencia.
La latencia también tiene una dimensión de diseño. Un usuario puede aceptar más tiempo si ve progreso, recibe resultados parciales o la tarea tiene valor alto. En una interfaz de soporte, cada segundo pesa más. En un análisis documental complejo, la espera puede ser razonable si el resultado llega bien estructurado y con fuentes.
Coste y latencia forman parte de la utilidad del sistema.
9. Descomponer workflows humanos
Una de las aptitudes menos visibles del IA Engineer consiste en entender cómo trabaja la gente antes de automatizar. Un proceso humano rara vez es una secuencia limpia. Suele incluir atajos, excepciones, aprobaciones, información tácita, herramientas paralelas y criterios que viven en la experiencia del equipo.
Descomponer un workflow significa identificar inputs, decisiones, actores, herramientas, tiempos, puntos de espera, errores frecuentes y salidas esperadas. También significa separar trabajo cognitivo, trabajo administrativo, comunicación, revisión y ejecución.
Esta lectura evita automatizaciones demasiado amplias. En muchos casos, el mayor retorno aparece al automatizar un tramo concreto: clasificar solicitudes, preparar borradores, extraer datos, revisar coherencia, comparar versiones, detectar excepciones o generar un resumen accionable.
El IA Engineer útil convierte un flujo humano en componentes. Algunos componentes pueden ser deterministas. Otros necesitan IA. Otros necesitan revisión humana. Otros requieren cambios de proceso antes de cualquier automatización.
Esta aptitud conecta directamente con una práctica de diagnóstico operativo. Antes de construir, se observa cómo circula la información, dónde se pierde tiempo, qué errores se repiten y qué decisiones requieren evidencia. La automatización nace de esa lectura.
10. Diseñar human-in-the-loop con precisión
La intervención humana aporta control cuando está situada en el punto adecuado. Un IA Engineer necesita decidir dónde entra la persona, qué información recibe, qué decisión debe tomar y cómo queda registrada esa decisión.
Un buen diseño evita revisiones genéricas. Pedir aprobación en cada paso reduce la utilidad del sistema. Pedir aprobación solo al final puede concentrar demasiado riesgo. La intervención humana funciona mejor cuando se activa por señales: acción irreversible, baja confianza, conflicto entre fuentes, impacto económico, datos sensibles o ambigüedad del usuario.
El diseño también debe cuidar la carga cognitiva. Una persona que revisa necesita ver el motivo de la alerta, la evidencia usada, la propuesta del sistema y las opciones disponibles. Aceptar, editar, rechazar o escalar deben ser acciones claras.
Esta aptitud tiene un valor especial en equipos pequeños. Permite automatizar más trabajo manteniendo control en los puntos donde el juicio humano aporta valor real. El sistema asume preparación, recopilación y propuesta. La persona conserva decisión en los puntos de responsabilidad.
11. Especificar comportamiento con instrucciones robustas
El prompting superficial pierde fuerza en sistemas complejos. Las instrucciones de un agente deben parecerse a una especificación de comportamiento. Deben definir rol, límites, prioridades, criterios de salida, formato, tratamiento de incertidumbre, uso de herramientas y reglas de escalado.
Una instrucción robusta ayuda al modelo a actuar de forma estable. Incluye ejemplos de comportamiento esperado y casos que requieren abstención, confirmación o derivación. También separa reglas permanentes de información temporal.
La calidad de estas instrucciones depende de la precisión. Un “sé útil” aporta poco control. Una regla como “cuando una acción implique enviar información fuera del sistema, muestra los datos que se transmitirán y solicita confirmación” convierte una intención de seguridad en comportamiento observable.
El IA Engineer debe escribir instrucciones como parte de la arquitectura. Cada instrucción importante merece versión, pruebas y trazabilidad. Cuando cambia, conviene saber qué casos mejora y qué casos puede afectar. Esta práctica acerca los prompts a la ingeniería de software: cambios pequeños, pruebas claras y registro de decisiones.
12. Diseñar degradación y recuperación
Los sistemas de IA viven en entornos con fallos. APIs que responden tarde. Modelos que cambian. Herramientas que devuelven errores. Documentos que faltan. Usuarios que escriben solicitudes ambiguas. Datos que llegan incompletos.
Un IA Engineer necesita diseñar rutas de recuperación. Qué ocurre cuando falla una herramienta. Qué mensaje recibe el usuario. Qué parte del trabajo puede completarse. Qué información debe conservarse. Qué acción queda bloqueada. Qué alternativa manual queda disponible.
La degradación bien diseñada mantiene utilidad parcial. Un agente que pierde acceso al CRM puede preparar un borrador con los datos disponibles y marcar los campos pendientes. Un asistente documental que encuentra fuentes contradictorias puede presentar ambas y pedir decisión. Un sistema de clasificación con confianza baja puede crear una cola de revisión.
Esta aptitud protege la experiencia de usuario y la confianza interna. Un sistema que falla de forma comprensible se puede mantener. Un sistema que falla de forma opaca genera rechazo.
13. Documentar decisiones técnicas y operativas
Los sistemas de IA cambian con rapidez. Cambian modelos, prompts, herramientas, políticas, datasets de evaluación, proveedores, precios y expectativas de usuario. Esa variación exige documentación viva.
Un IA Engineer necesita registrar decisiones relevantes: por qué se eligió un modelo, qué dataset evalúa el flujo, qué herramientas tienen permisos, qué prompts están en producción, qué cambios se han hecho, qué riesgos se aceptan y qué métricas definen calidad.
La documentación útil se integra con el trabajo: changelogs de prompts, versionado de evals, trazas representativas, catálogo de herramientas, matriz de permisos, taxonomía de fallos, registro de incidencias, decisiones de routing y criterios de retirada de memoria.
Esta documentación permite que el sistema sea mantenible por un equipo pequeño. También facilita auditoría, onboarding y mejora continua.
14. Elegir el nivel correcto de automatización
La aptitud más madura del IA Engineer consiste en elegir cuánto automatizar. Cada tarea tiene un nivel adecuado de autonomía. Algunas solo necesitan ayuda para redactar. Otras necesitan extracción estructurada. Otras admiten ejecución completa. Otras requieren preparación asistida y decisión humana.
Automatizar parcialmente suele generar mejores resultados en fases iniciales. Un sistema que prepara, ordena y verifica puede ahorrar mucho tiempo con riesgo controlado. A partir de ahí, los datos de uso y las evaluaciones indican qué tramos merecen más autonomía.
Esta aptitud conecta ingeniería y estrategia. El IA Engineer debe mirar el coste oculto del proceso, la frecuencia de la tarea, la gravedad del error, la disponibilidad de datos, la madurez del equipo y la facilidad de integrar el sistema en las herramientas existentes.
La pregunta operativa pasa a ser concreta: qué parte del trabajo puede pasar de dispersa a estructurada, de manual a asistida, de asistida a automatizada y de automatizada a supervisada por métricas.
El perfil que emerge
El IA Engineer valioso combina varias capas de criterio. Sabe trabajar con modelos y procesos. Sabe usar herramientas y definir sus límites. Sabe construir agentes y medirlos. Sabe escribir instrucciones y observar si esas instrucciones producen comportamiento estable.
Sus aptitudes poco nombradas tienen un rasgo común: hacen visible el sistema. La evaluación hace visible la calidad. La observabilidad hace visible el recorrido. La taxonomía de fallos hace visible la causa. Los contratos de herramientas hacen visible la responsabilidad. Los permisos hacen visible el riesgo. La documentación hace visible la evolución.
En un entorno de modelos cada vez más capaces, la diferencia se desplaza hacia la ingeniería del contexto en el que esos modelos actúan. Un modelo potente puede generar una respuesta. Un sistema bien diseñado puede sostener un proceso.
Para empresas pequeñas, equipos de producto y operaciones internas, esta distinción tiene consecuencias prácticas. La IA empieza a aportar valor cuando entra en tareas reales con límites definidos, medición suficiente y mantenimiento posible. La promesa deja de depender de una demo y pasa a depender de un sistema que se puede explicar.
Conclusión
Las aptitudes menos comentadas del IA Engineer forman una disciplina de claridad operativa. Evaluar. Trazar. Clasificar fallos. Gestionar contexto. Diseñar herramientas. Limitar permisos. Curar datos. Medir coste y latencia. Descomponer workflows. Documentar decisiones.
Ese conjunto convierte la IA en infraestructura de trabajo. También marca una diferencia cultural: construir con IA exige observar mejor, decidir mejor y mantener mejor.
En Anemonautas lo formulamos así: antes de automatizar, entendemos cómo se trabaja. La ingeniería de IA con impacto empieza ahí, en la capacidad de convertir procesos dispersos en sistemas claros y sostenibles.