14. El rol transversal
1 · QUÉ ES — PARA PROFANOS
Tienes razón: este rol es transversal. La propia JD lo dice — y lo dice más veces que de la
tecnología.
El AI Expert de esta oferta no es un científico en un laboratorio ni un programador en su esquina.
Es el que vive en medio de la mesa: negocio trae necesidades, seguridad pone límites, data
tiene los datos, software tiene las aplicaciones, producto decide prioridades. El ingeniero de IA
es el puente entre todos — y su trabajo es que la solución cruce ese puente entera.
La metáfora del intérprete: en una mesa donde cada uno habla su idioma, el rol transversal es el
que traduce: la necesidad de negocio a requisito técnico, el requisito a arquitectura, la
arquitectura a código, y el código a una explicación que cada interlocutor entiende. Sin esa
traducción, la mejor solución muere en la reunión.
Por qué esto decide la contratación: los temas técnicos (documentos 01-10) te meten en la
entrevista. El rol transversal te da el puesto. Un candidato muy técnico pero incapaz de
explicarse es un riesgo; un candidato sólido que además traduce, es un multiplicador. Y en un banco,
donde cada decisión de IA la firman cinco áreas distintas, el multiplicador es el perfil.
Estas líneas estaban en la oferta y no cabían en los diez temas anteriores:
> "Colaborar con equipos multidisciplinares (Software Engineers, Arquitectura, Data, Seguridad,
> Producto)".
>
> "Comunicación clara, tanto con audiencias técnicas como no técnicas."
>
> "Trabajo en equipo y en entornos colaborativos, con metodologías ágiles."
>
> "Documentar arquitecturas, decisiones técnicas y componentes desarrollados."
>
> "Mantenerse actualizado/a sobre la evolución de modelos, frameworks y herramientas."
>
> "Capacidad de experimentación y prototipado rápido."
La lectura honesta: la mitad de la oferta no pide saber tecnología — pide saber trabajar con
gente alrededor de la tecnología. Cinco equipos citados por su nombre. Comunicación con dos
audiencias. Agile. Documentación. Eso no es el relleno de la oferta: es el trabajo.
Y es exactamente lo que se quedó sin demostrar en la entrevista de junio — donde la impresión
fue la de un constructor solitario ("me lo he construido todo"). Este documento existe para que la
misma trayectoria se cuente como lo que es: un rol transversal ejercido con los recursos
disponibles.
- Equipos de plataforma de IA: en las empresas grandes, el AI Engineer vive en una plataforma
transversal que sirve a todos los dominios de negocio. Colaborar con todos los equipos no es un
trámite: es la definición del puesto. Por eso la JD lo pone primero.
- Documentos de diseño antes de código (design docs / RFC): las decisiones se escriben, se
circulan y se discuten antes de construir. La línea de la JD sobre "documentar decisiones
técnicas" es literalmente esto. Quien documenta decisiones, deja de ser un ejecutor y pasa a
ser una referencia.
- El perfil más buscado no es el más técnico: es el que habla con negocio sin perder rigor y con
seguridad sin perder el hilo. El sector lo llama "AI translator" — y paga por él.
- Equipos con agentes dentro: los equipos de 2026 incluyen agentes como un miembro más, con sus
tareas, su medición y sus límites. Saber coordinar agentes es literalmente saber trabajar en
equipo — mismo oficio: contratos claros, medición continua, corrección sin drama.
- Estar al día como sistema, no como hobby: newsletters, paper clubs… y cada vez más, evals
propios. El que no mide modelos lee reseñas; el que mide escribe las suyas. Nosotros somos del
segundo grupo.
1 · El ecosistema ES un equipo — y lo dirigimos como tal. Seis agentes con roles diferenciados:
Angi (PM), Zalo (coordinación), Lisa (planificación), Tom (worker), Campo y Gon (contenidos). Cada
uno con su contrato, su medición cada seis horas y sus límites. Coordinar este equipo es el mismo
oficio que coordinar personas con roles: definir qué hace cada uno, medirlo, detectar al que
degrada (la tabla del documento 05 lo registra: gon bajó a 2,8 y el sistema lo dejó escrito) y
corregir sin drama. Cuando la JD pide "trabajo colaborativo", esta es nuestra práctica diaria de
colaboración — con un equipo que no duerme.
2 · La evidencia histórica de traducir entre mundos técnicos y no técnicos:
- La capa Python sobre Caché (2007): un equipo entero no sabía MUMPS — les construí una capa en
su idioma. Eso es exactamente "comunicación con audiencias técnicas distintas".
- Migraciones en ~15 hospitales y 50 clínicas: hablar con usuarios finales, jefes de servicio y
administración sobre sistemas sanitarios. Eso es exactamente "audiencias no técnicas".
- Werfen, +40 hospitales y guardias 24/7: operación bajo presión y comunicación con equipos de
TI hospitalaria. Eso es exactamente "entorno colaborativo".
3 · La documentación como producto, no como papeleo. El formato de casa para toda decisión:
problema → opciones consideradas → elección → por qué → condición que haría replanteársela. Es el
formato que sobrevive a las auditorías y el que permite a un recién llegado entender el porqué en
una tarde. La serie de documentos que estás leyendo es, ella misma, la demostración del oficio:
tecnología explicada a profanos, sin bajar el rigor.
4 · Estar al día, convertido en sistema. Evaluación cada 6 horas, cadena de modelos revalidada
dos veces al día, ciclo semanal que propone pruebas nuevas. "Mantenerse actualizado" no es leer
titulares: es tener un sistema que te dice qué modelo empeoró esta noche.
5 · La cara práctica del rol transversal: integrar, no solo construir. La IA no vive sola —
vive conectada: la API de Zalo en Workers, SentryAI en FastAPI, el nodo local en HTTP:8140,
los 25 servidores MCP. Integrar modelos en aplicaciones que ya existían — que es otra línea de la
JD — es lo que hacemos cada día: cada agente es una integración.
Y la honestidad que cierra el círculo: el ciclo completo lo hemos llevado en solitario técnico.
Por eso lo más valioso que aporta un equipo como el de Getnet no es dividir el trabajo: es
multiplicarlo — y es exactamente lo que venimos a buscar.
> Las seis líneas de la sección 2: colaboración multidisciplinar, comunicación dual, Agile,
> documentación, actualización continua y prototipado rápido.
"Has trabajado mucho en solitario. ¿Cómo vas a trabajar en equipo?" (la pregunta que decidió
junio — ahora con respuesta)
> "En solitario, pero nunca solo: llevo años coordinando un equipo de agentes con roles, contratos
> y medición cada seis horas — el mismo oficio que coordinar personas. Y antes de eso, quince
> hospitales y cincuenta clínicas en migraciones, cuarenta hospitales con Werfen, guardias
> veinticuatro-siete. Mi trayectoria no es la de un lobo estepario: es la de alguien que ha hecho de
> cada rol — arquitectura, datos, seguridad, producto — porque era lo que el proyecto pedía. Lo que
> más me interesa de Getnet es exactamente esto: dejar de ser el único y multiplicar."
"¿Cómo explicas la IA a gente no técnica?"
> "Hablo de decisiones, no de modelos. Nunca digo 'el modelo hizo X': digo 'el sistema decidió X
> con esta información, bajo esta regla, y esto quedó registrado'. Las metáforas para el concepto —
> el becario, el historial del paciente — y los números para la confianza. Y una regla: si no sé
> explicárselo a mi padre, es que yo tampoco lo entiendo del todo."
"¿Cómo colaborarías con el equipo de Seguridad?"
> "En su idioma, que es el mío: permisos, alcance, trazas. Mi control de acceso vive en la
> consulta, mi validador registra las desviaciones y el razonamiento se filtra por nivel de
> confianza. Cuando me siente con Seguridad no les explicaré qué es un LLM: les enseñaré el esquema
> de datos y el registro — y la conversación será sobre SU terreno desde el primer minuto."
"¿Cómo te mantienes al día?"
> "Con un sistema, no con lecturas: mi batería evalúa seis agentes cada seis horas y mi cadena de
> modelos se revalida dos veces al día contra un ancla de pago. Cuando un modelo nuevo entra en la
> cadena, lo veo en los números antes de leer la reseña. Y cada semana el propio ciclo propone
> pruebas nuevas. Estar al día, para mí, es medir — las reseñas vienen después."
"¿Cómo documentas las decisiones?"
> "Como decisiones, no como descripciones: problema, opciones, elección, por qué, y qué condición
> haría replanteársela. Es el formato que permite a un compañero nuevo entender el porqué en una
> tarde, y el que sobrevive a una auditoría. Lo aplico igual a un esquema de datos que a un
> proveedor de nube."