En el módulo 8 armamos el presupuesto y aprendimos a leer el costo unitario de un producto de IA: ya sabemos qué cuesta. Pero un presupuesto es una lista de recursos, y los recursos más caros de esta lista no son las GPU ni los tokens: son las personas. Y las personas, a diferencia de una factura de nube, no se coordinan solas. Puedes tener aprobado el dinero, comprado el cómputo y elegido el enfoque, y aun así el proyecto se te muere — no por falta de plata ni de tecnología, sino porque el que conoce el negocio, el que entrena el modelo y el que lo mantiene en producción nunca se pusieron de acuerdo sobre quién decide qué. Este módulo es sobre eso: quién hace qué, y cómo se organizan para que el trabajo no se caiga en las junturas.

La tesis del módulo

Un producto de IA falla por organización tan seguido como por tecnología. Si el que conoce el negocio, el que entrena el modelo y el que lo opera no comparten un modelo operativo claro, el proyecto se muere en los traspasos: en el hueco entre “el modelo funciona en mi notebook” y “el modelo funciona en producción”, entre “el negocio pidió esto” y “el equipo entendió esto otro”. Los proyectos de IA rara vez se caen por el centro de una responsabilidad; se caen por el borde, ahí donde nadie era claramente el dueño.

Los roles de un equipo de IA

Un producto de IA reúne oficios que en la organización suelen vivir separados: gente de negocio, de ingeniería de software, de datos y de operación. No todos hacen falta desde el día uno, pero conviene conocerlos a todos para saber cuál te está faltando. Cada rol se define por dos cosas: de qué es responsable y — igual de importante — de qué NO lo es, porque el error organizacional más común es asumir que “alguien” cubre una frontera que en realidad quedó sin dueño.

Dueño de producto de IA (AI Product Manager: quien decide qué se construye y por qué). Traduce el problema de negocio en un producto, prioriza, define el criterio de éxito y protege el alcance. No entrena el modelo ni escribe el pipeline: decide qué problema se ataca, no cómo se resuelve técnicamente.
Ingeniero de ML/IA (ML engineer: quien construye el modelo o el sistema que lo usa). Elige el enfoque técnico, arma el prompt o el fine-tuning, integra la API, monta el sistema de recuperación. Su frontera: no decide la prioridad del negocio ni el presupuesto, y no es dueño de que el dato de entrada esté limpio.
Ingeniero de datos (data engineer: quien mueve y prepara los datos). Construye las tuberías que llevan el dato desde donde vive hasta donde el modelo lo necesita, con la calidad y la frescura que hace falta. No modela: entrega materia prima usable. En muchos proyectos de IA este rol es el cuello de botella real y el que menos se planifica.
MLOps / plataforma (Machine Learning Operations: quien mantiene el modelo vivo en producción). Despliegue, monitoreo, versionado, reentrenamiento, control de costo en operación. Es la diferencia entre un modelo que funcionó una vez y un modelo que sigue funcionando en seis meses. Es el rol que más se olvida en el plan y el que más incendios apaga después. Su mundo es el del curso de MLOps.
Experto de dominio (domain expert: quien conoce el negocio por dentro). El médico, el abogado, el analista de crédito, el agente de soporte con diez años de oficio. Sabe qué respuesta es correcta y cuál es un desastre disfrazado de correcta. No programa: valida, define casos, detecta el error que el equipo técnico no puede ver porque no vivió el problema.
Anotadores / etiquetadores (annotators: quienes marcan la respuesta correcta en los datos). Producen los datos etiquetados que entrenan o evalúan el modelo. Un rol subestimado: la calidad de su trabajo pone el techo de la calidad del modelo. No definen el criterio de etiquetado — eso lo fija el dominio junto al PM —, lo aplican de forma consistente.
Diseño / UX de IA (User Experience: cómo se siente usar el producto). En IA el diseño tiene un trabajo extra: comunicar la incertidumbre. Un modelo que a veces se equivoca necesita una interfaz que lo deje claro, que ofrezca corregir, que no venda como certeza lo que es una probabilidad. No decide el modelo: decide cómo se presenta su falibilidad al humano.
Riesgo / legal (compliance: quien vela por que sea legal y aceptable el riesgo). Privacidad de datos, sesgo, cumplimiento regulatorio, riesgo reputacional. Entra pronto o entra tarde y caro. Todo su mundo es el módulo 10; acá basta con saber que es un rol, no un trámite del final.

Equipo chico vs. equipo grande

En un equipo chico una persona lleva varios sombreros, y eso está bien — mientras se sepa cuáles. El peligro no es que el PM haga también de ingeniero de datos; el peligro es que nadie sepa que el sombrero de ingeniero de datos existe y quedó sin cabeza.

Rol	Equipo chico (piloto)	Equipo grande (producto en escala)
Dueño de producto de IA	Imprescindible, dedicado	Imprescindible, dedicado
Ingeniero de ML/IA	Imprescindible (suele hacer también MLOps)	Varios, especializados
Ingeniero de datos	Crítico; a veces lo cubre el de ML	Rol propio y dedicado
MLOps / plataforma	Compartido con ML al principio	Rol propio; es lo primero que se separa
Experto de dominio	Imprescindible, aunque sea a tiempo parcial	Panel de expertos, formal
Anotadores	El propio equipo etiqueta al inicio	Equipo dedicado o servicio externo
Diseño / UX	Compartido con producto general	Especialista en UX de IA
Riesgo / legal	Consultado en hitos clave	Involucrado de forma continua

Ojo: el rol que más se subestima al empezar es MLOps, y el que más proyectos hunde por su ausencia es el ingeniero de datos. Un piloto puede vivir un tiempo sin plataforma formal, pero no puede vivir sin alguien responsable de que el dato llegue limpio. Si en tu plan de equipo no hay una cabeza clara para los datos, ese es el primer agujero que tapar.

El modelo operativo: dónde vive el equipo

Definidos los roles, la pregunta siguiente es estructural: ¿cómo se organiza esa gente dentro de la empresa? Hay tres patrones clásicos, y ninguno es el correcto en abstracto — cada uno resuelve un problema y crea otro.

Equipo dedicado (dedicated team: un equipo autónomo que es dueño del producto de punta a punta). Tiene sus roles adentro y responde por el resultado completo. Máxima velocidad y foco; riesgo de convertirse en una isla que reinventa lo que otros ya resolvieron.
Centro de excelencia (Center of Excellence, CoE: un equipo central de expertos de IA que da servicio a toda la empresa). Concentra el talento escaso, fija estándares y evita que cada área improvise. Pero se vuelve cuello de botella: todos lo necesitan, nadie es su prioridad, y queda lejos del negocio real.
Embebido en producto (embedded: los especialistas de IA se reparten dentro de los equipos de producto existentes). Cercanía total al negocio y al usuario; riesgo de aislar a los técnicos de IA entre sí, que dupliquen esfuerzo y pierdan el estándar común.

Muchas empresas maduras terminan en un modelo híbrido: un centro de excelencia chico que fija estándares y herramientas comunes, con especialistas embebidos en los equipos de producto que hacen el trabajo cerca del negocio. El CoE no hace el producto: habilita a los que lo hacen.


        MODELO HÍBRIDO: CoE + EMBEBIDOS

  ┌──────────────────────────────────────────┐
  │   Centro de Excelencia: estándares,      │
  │   plataforma MLOps, evals, prácticas     │
  └──────┬──────────────┬──────────────┬─────┘
         │ habilita     │ habilita     │
         ▼              ▼              ▼
  ┌────────────┐  ┌────────────┐  ┌────────────┐
  │  Producto  │  │  Producto  │  │  Producto  │
  │     A      │  │     B      │  │     C      │
  │  PM + ML   │  │  PM + ML   │  │  PM + ML   │
  │  embebido  │  │  embebido  │  │  embebido  │
  └──────┬─────┘  └──────┬─────┘  └──────┬─────┘
         │               │               │
         └───────────────┼───────────────┘
                         ▼ prioridad + presupuesto
                  ┌────────────────┐
                  │    Negocio     │
                  │ (patrocinador) │
                  └────────────────┘

El diagrama muestra el flujo de decisión que importa: el negocio decide qué y cuánto (prioridad y presupuesto, lo del módulo 6 y el 8), los equipos de producto deciden cómo cerca del usuario, y el CoE garantiza que todos los “cómo” compartan un mismo piso de calidad y herramientas. Cuando ese flujo se rompe — cuando el negocio quiere decidir el “cómo” técnico, o el CoE quiere decidir la prioridad del negocio — es cuando empiezan las peleas.

La matriz RACI: quién decide qué

Los roles dicen qué hace cada persona. Pero producto de IA está lleno de decisiones que cruzan roles, y ahí la pregunta no es “¿quién trabaja en esto?” sino “¿quién tiene la última palabra?”. La herramienta clásica para eso es la matriz RACI, y en IA se gana el sueldo, porque estas decisiones mezclan criterio técnico, de negocio y de riesgo, y el que decide una no es el que decide la otra.

RACI asigna a cada decisión cuatro tipos de participación:

R — Responsible (responsable de ejecutar): quien hace el trabajo de la decisión. Puede haber varios.
A — Accountable (rinde cuentas): quien tiene la última palabra y responde por el resultado. Exactamente uno por decisión — esta es la regla que más se rompe y la que más caos evita cuando se respeta.
C — Consulted (consultado): quien da opinión antes de decidir. Comunicación de ida y vuelta.
I — Informed (informado): a quien se le avisa después. Comunicación de una vía.

La regla de oro: una y solo una A por fila. Si dos personas rinden cuentas por la misma decisión, en la práctica no rinde cuentas ninguna. Si ninguna la tiene, la decisión se pospone para siempre en un correo que nadie contesta.

Artefacto: matriz RACI de un producto de IA

Esta es una tabla de ejemplo — los roles y las A concretas dependen de tu organización, pero la forma sirve tal cual. Fíjate en que la A se mueve de columna según la naturaleza de la decisión: técnica, de negocio o de riesgo.

Decisión	AI PM	ML eng.	MLOps	Dominio	Riesgo/legal	Patrocinador
Elegir el enfoque/modelo	C	A	C	I	I	I
Definir el criterio de éxito	A	C	I	C	I	C
Aprobar el lanzamiento	C	C	C	C	C	A
Aceptar un riesgo conocido	C	I	I	C	A	C
Cambiar el prompt en producción	I	A	C	C	I	I
Cortar el modelo por incidente	I	C	A	I	C	I

Léela por columnas y salta a la vista la lógica: el ML engineer rinde cuentas por las decisiones técnicas (qué modelo, qué prompt), pero no por el lanzamiento ni por aceptar un riesgo; el patrocinador aprueba el lanzamiento porque es quien responde ante el negocio, pero no elige el modelo; riesgo/legal es el único que puede decir “acepto este riesgo por escrito”, y nadie más debería hacerlo en un pasillo. Y una fila operativa clave: cortar el modelo por un incidente en producción es de MLOps, no del PM — cuando algo se rompe a las 3 de la madrugada, tiene que estar clarísimo de antemano quién tiene el botón, o se pierden horas caras averiguándolo.

Cuidado: una RACI donde el PM aparece con A en todo no es una RACI, es un cuello de botella con formato de tabla. El punto del ejercicio es repartir la última palabra según la competencia real: hay decisiones que el PM no debe tomar solo (elegir el modelo, aceptar un riesgo legal) y decirlo por escrito lo libera a él y protege al proyecto.

Negocio ↔ técnica: el traductor y su doble deber

El corazón de un equipo de IA sano es un puente de dos direcciones entre el negocio y lo técnico, y las dos direcciones fallan por su cuenta:

El PM debe entender lo suficiente de IA para no prometer imposibles. Todo este catálogo de módulos existe en parte para eso. Un PM que promete “cero errores” en un sistema probabilístico, que confunde una demo afortunada con factibilidad, o que compromete una fecha sin un spike (módulo 3), le clava al equipo una promesa que nadie puede cumplir. No necesita programar; necesita saber qué se puede pedir y qué no.
El técnico debe entender lo suficiente de negocio para no optimizar la métrica equivocada. Un ingeniero que sube la precisión del modelo tres puntos mientras el negocio necesitaba bajar la latencia, o que optimiza un promedio cuando lo que dolía era el caso crítico, está trabajando bien en la dirección incorrecta. La métrica técnica sirve a un objetivo de negocio (módulo 7); perder ese hilo es trabajar duro para nada.

Cuando estas dos comprensiones existen, la RACI se llena sola y las reuniones son cortas. Cuando faltan, ninguna tabla las reemplaza: el PM sigue prometiendo lo imposible y el técnico sigue puliendo lo que no importa, cada uno convencido de que hace bien su parte.

Cultura de datos y evals: el dueño de la calidad y la trampa del héroe

Hay una pregunta que ningún organigrama contesta y que decide la salud del producto a mediano plazo: ¿quién es dueño de la calidad? No de escribir el modelo, sino de que el modelo siga siendo bueno: que los datos no se degraden, que los evals corran, que una caída de calidad tenga un dueño que la note y la arregle. En muchos equipos esa responsabilidad no está asignada a nadie, y por eso la calidad se erosiona en silencio hasta que un cliente reclama.

Y está la trampa del héroe. En casi todo equipo de IA hay una persona que “entiende el modelo de verdad” — cómo se comporta, por qué falla, qué lo mejora. Mientras esa persona está, todo fluye. El día que se va de vacaciones, se enferma o renuncia, el equipo descubre que nadie más sabe operar lo que construyeron. El héroe no es el problema; el problema es la organización que lo dejó ser el único punto de conocimiento.


     LA TRAMPA DEL HÉROE (Y SU ANTÍDOTO)

  antipatrón:               antídoto:
  ┌─────────────┐           ┌─────────────┐
  │    héroe    │           │    equipo   │
  │  sabe todo  │           │  documenta, │
  │             │           │ rota, sabe  │
  └──────┬──────┘           └──────┬──────┘
         │ único                   │ saber
         │ punto                   │ repartido
         ▼                         ▼
  ┌─────────────┐           ┌─────────────┐
  │  producto   │           │  producto   │
  │  frágil:    │           │  robusto:   │
  │  se va y    │           │  el bus no  │
  │  se cae     │           │  lo tumba   │
  └─────────────┘           └─────────────┘

El antídoto no es heroico ni glamoroso: documentar las decisiones, rotar quién toca el modelo, hacer que el conocimiento del héroe se derrame al equipo. Se mide con una pregunta incómoda — el factor bus (cuántas personas tendrían que faltar de golpe para que el producto quede sin nadie que lo entienda). Si la respuesta es “una”, tienes un riesgo operativo tan real como cualquier bug, solo que este no aparece en ningún log.

Errores comunes

Silos. Datos por un lado, modelado por otro, operación por otro, cada uno con su jefe y su prioridad. El producto de IA es un flujo continuo del dato al valor; partirlo en feudos garantiza que el trabajo se atasque en cada frontera. La estructura debe seguir el flujo, no el organigrama heredado.
Traspaso PoC → producción sin dueño. El equipo que hizo la prueba de concepto la lanza “por encima del muro” a operaciones y se desentiende. Nadie es dueño del sistema en producción, y el primer incidente encuentra a un equipo que ya no lo mira y a otro que nunca lo entendió. El dueño de producción se nombra antes del traspaso.
No tener un dueño de la calidad del dato. Todos usan los datos, nadie responde por ellos. Se degradan de a poco, sin culpable, hasta que el modelo empeora y la investigación tarda semanas porque no hay a quién preguntarle.
Confundir “científico de datos” con “ingeniero de producción”. Quien explora, prueba enfoques y arma un prototipo en un notebook no es necesariamente quien sabe (ni quiere) mantener un servicio con 99,9% de disponibilidad. Son oficios distintos; asumir que la misma persona hace ambos bien es cómo mueren los proyectos en la juntura entre el experimento y la operación.
Una RACI donde todo es A del PM. Concentrar la última palabra en una persona no es liderazgo, es cuello de botella. Las decisiones técnicas, de negocio y de riesgo tienen dueños distintos, y escribirlo así reparte la carga y acelera todo.
El héroe como estrategia. Depender de que una sola persona entienda el modelo. Funciona hasta que esa persona no está, y entonces no funciona nada. El conocimiento que no se comparte es deuda esperando el peor momento para cobrarse.

La frase para llevarse

“Los productos de IA no se caen por el centro de una responsabilidad, se caen por el borde — ahí donde el negocio creyó que lo cubría el técnico, el técnico creyó que lo cubría el de datos, y nadie era el dueño. El modelo operativo no es burocracia: es el mapa de quién agarra la pelota antes de que toque el suelo.”

Qué viene

Módulo 10: riesgo y cumplimiento. Ya tenemos el equipo y sabemos quién decide qué — incluida la fila más delicada de la RACI: quién puede aceptar un riesgo. En el próximo módulo abrimos esa caja entera. Qué riesgos son propios de un producto de IA (sesgo, privacidad, alucinación, decisiones automatizadas sobre personas), cómo se identifican antes de que exploten, qué exigen marcos como el NIST AI RMF y regulaciones como el EU AI Act, y cómo se convierte “esto es riesgoso” en un plan concreto con dueño y fecha, en vez de un miedo difuso que paraliza o, peor, que se ignora hasta el incidente.

Producto de IA — Módulo 9: equipo y modelo operativo