Tres topologías y una ley laboral de 2021 deciden cómo trabaja un equipo de IA. Montar un equipo de ciencia de datos y colgarlo del área de tecnología no convierte a una empresa en una organización de producto de IA. La unidad de trabajo ya no es una funcionalidad con un resultado conocido, sino un modelo que se comporta de forma probabilística: se degrada cuando cambia el mundo, depende de datos que alguien tiene que conseguir y defender, y arrastra obligaciones legales que el ágil clásico nunca tuvo que pagar.
Si el diseño organizativo no lo tiene en cuenta, cada una de esas presiones vuelve más tarde convertida en una cola de seis meses, un conjunto de datos sin trazabilidad o un modelo que nadie se atreve a aprobar. ¿Quién responde por un modelo que falla a las dos de la madrugada? Si cuesta contestar, el organigrama ya está mal.
Tres topologías que aparecen en casi toda empresa de IA
La mayoría se asienta en una de tres estructuras, y cuál sirve depende de la escala y la madurez. La más común es la plataforma bajo los equipos de aplicación: la plataforma es dueña de las herramientas comunes (dónde se guardan los datos que usan los modelos, cómo se entrenan y ajustan, el registro de versiones, las pruebas de calidad y los controles automáticos). Los equipos de aplicación responden de un problema de producto de principio a fin, de sus experimentos y del resultado de negocio. La plataforma existe para quitar carga a los equipos que entregan valor al cliente y para que vayan más rápido; si los frena, sobra.
Muchas empresas arrancan con un centro de excelencia que concentra el talento escaso, fija estándares y prototipa rápido. El caso español más citado es el de BBVA, que en junio de 2019 creó en Madrid su AI Factory, con unos 150 profesionales entre científicos de datos, ingenieros y representantes de negocio, y con el encargo explícito de construir capacidades que se reutilizaran en varios países y unidades.
Ese último punto es el que suele faltar: un centro de excelencia que no diseña para la reutilización acaba siendo una cola. Cuando la demanda la supera, las áreas que no pueden esperar montan equipos paralelos fuera de los estándares.
La estructura en la que terminan la mayoría de las grandes organizaciones es la federada: una plataforma central dueña de la infraestructura y la gobernanza, equipos de aplicación por dominio con científicos de datos integrados y una autoridad única sobre las definiciones de métricas y de costes compartidos. Escala con coherencia mientras esa autoridad exista. Sin ella, cada dominio acaba midiendo "usuario activo" a su manera, y reconciliar tres definiciones un año después cuesta más que haberlas pactado al principio.
La regla para pasar de una forma a otra es sencilla de enunciar: cuando la espera media en la cola central supera un ciclo de planificación (normalmente un trimestre) y al menos dos áreas han contratado perfiles de IA por su cuenta, toca federar. Si la espera cabe en el trimestre, mejor quedarse donde se está e invertir en estándares, porque federar antes de tiempo reparte un talento escaso y nadie profundiza.
La frontera de la plataforma se traza por frecuencia de cambio
El error recurrente al montar la estructura federada es dividir por tecnología: la plataforma se queda con "todo lo de modelos" y la aplicación con "todo lo de producto". Suena ordenado y falla rápido. Los prompts, los criterios de evaluación y los umbrales de las salvaguardas (los límites que el modelo no debe cruzar) cambian con cada iteración de producto y no pueden vivir en un componente central que se despliega una vez al trimestre.
La razón es organizativa: cada frontera entre equipos acaba siendo una frontera del sistema, con su cola y su reunión. Si la plataforma es dueña de los prompts, cada cambio de prompt se convierte en una conversación entre dos equipos, y el producto hereda esa fricción. Basta una cuenta rápida.
Un equipo de aplicación que ajusta prompts tres veces por semana y depende de una plataforma que despliega cada martes espera, de media, unos tres días y medio por cambio. En un trimestre son unos 36 cambios y más de 100 días acumulados de espera. El mismo equipo, dueño de sus prompts, despliega en horas.
La línea útil sigue la frecuencia de cambio. Lo que ya no cambia y usan todos (el almacén de datos para modelos, el control de versiones, la vigilancia del modelo en producción) baja a la plataforma; lo que se reescribe cada semana para un dominio se queda en el equipo que responde de su resultado.
Hay un síntoma fiable de frontera mal puesta: si los equipos de aplicación esperan a la plataforma para cambiar un prompt, la línea está en el sitio equivocado. Añadir gente a la plataforma no lo arregla, porque el problema está en quién es dueño de qué; la capacidad es secundaria.
Cada perfil resuelve una pregunta distinta
Los productos de IA exigen roles que el software clásico no tiene o define de otra manera, porque alguien tiene que responder del ciclo de vida del modelo, de los datos, de la evaluación y de la gobernanza. La forma más útil de describirlos es por la pregunta que cada uno contesta cuando algo se rompe.
El product manager de IA contesta "¿por qué existe este modelo y cómo sabemos que funciona?". Plantea el problema y la hipótesis, comprueba si existen los datos, fija los criterios de evaluación y las salvaguardas, es dueño del plan de experimentación y mantiene a ingeniería, ciencia de datos y asesoría jurídica apuntando al mismo objetivo. En muchas empresas españolas, sobre todo en banca y en grandes consultoras, este papel aparece en las ofertas como "Product Owner", herencia de la adopción de Scrum. Conviene leer la descripción antes que el título, porque a veces es un gestor de backlog sin capacidad de decidir sobre el modelo.
El científico de datos contesta "¿qué se puede aprender de estos datos?". Prepara los datos, prueba el modelo antes de lanzarlo, cuida el rigor estadístico y monta prototipos que dicen pronto si una idea es viable. El ingeniero de ML contesta "¿aguanta en producción, a escala real?". Integra y despliega el modelo, vigila que responda rápido y detecta la deriva: el cambio de comportamiento cuando cambian los datos de entrada.
El ingeniero de MLOps cuida lo que nadie ve: que el modelo se pueda vigilar, que se reentrene solo cuando toca y que cada versión quede registrada. Los especialistas en evaluación y seguridad construyen los conjuntos de referencia, ejemplos etiquetados que no cambian entre versiones para que la comparación sea justa, y ponen a prueba el modelo contra alucinaciones, sesgos y ataques antes de producción.
Los diseñadores hacen legible la incertidumbre. Y el responsable de gobernanza de datos responde de dónde salió cada dato y con qué base legal puede usarse.
En una empresa pequeña la tentación es fusionar estos roles en dos o tres personas, y hasta cierto tamaño funciona. El punto en que deja de funcionar se reconoce bien: cuando la misma persona escribe el criterio de evaluación y decide si el modelo lo supera.
Lo que pasa después es previsible. Quien fija el umbral y lo mide a la vez tiene todos los incentivos para ajustar uno de los dos. Separar ambas funciones sigue el mismo principio por el que quien escribe el código no firma su propia revisión de seguridad.
Cómo circula el trabajo del problema al lanzamiento
El camino hasta producción es iterativo y su secuencia no es la del software clásico:
- El PM define el problema, las hipótesis y los criterios de evaluación.
- El científico de datos evalúa la viabilidad de los datos.
- Los ingenieros de ML construyen prototipos con el científico de datos.
- PM y científico de datos evalúan el rendimiento offline.
- Ingeniería integra el modelo en la experiencia de usuario.
- El PM ejecuta experimentos online.
- Seguridad valida que está listo.
- MLOps despliega, vigila y reentrena.
Las flechas vuelven atrás. Una evaluación offline floja en el paso cuatro devuelve el trabajo al paso dos, no al cinco. Un experimento online que no mueve la métrica en el paso seis puede revelar que la hipótesis del paso uno era errónea, y no el modelo. El equipo tiene que estar montado para volver atrás a bajo coste.
La evaluación tampoco es una fase final. Entra en la semana normal. El PM mira cuántas respuestas acierta el modelo y cuántas se le escapan, cuánto tarda, cuántas veces inventa, el coste por inferencia y las señales de deriva, igual que un PM de SaaS lee un embudo. El código del modelo es una parte pequeña del sistema, y la deuda técnica se acumula alrededor: en los datos, la configuración y la monitorización. Un equipo que solo mira la métrica del modelo mira la parte menor del problema.
La gobernanza va integrada por la misma razón: controles en el origen de los datos, en la documentación del modelo, en las pruebas contra prompts maliciosos, en el aviso de IA en la interfaz y en el paso con intervención humana.
Cuando el modelo decide sobre personas, también responde ante el comité de empresa
En España hay una obligación que muchos equipos de producto descubren tarde. Desde el Real Decreto-ley 9/2021, convertido después en la Ley 12/2021 y conocido como ley rider, el artículo 64.4 d) del Estatuto de los Trabajadores reconoce al comité de empresa el derecho a ser informado de los parámetros, reglas e instrucciones en los que se basan los algoritmos o sistemas de IA que afectan a decisiones sobre condiciones de trabajo, acceso y mantenimiento del empleo, incluida la elaboración de perfiles.
Si tu producto se usa dentro de la empresa para asignar turnos, priorizar candidatos, medir productividad o repartir tareas, esa información tiene que existir y tiene que poder explicarse en un lenguaje que entienda la representación de los trabajadores. Y si lo vendes a terceros, tus clientes te la van a pedir. Un cliente grande lo preguntará en la primera ronda de compras, antes incluso de hablar de precio.
Para el diseño del equipo, la consecuencia es concreta: la persona responsable de gobernanza necesita un canal estable con recursos humanos y con la asesoría laboral, y la documentación del modelo debe redactarse pensando también en ese lector, no solo en el auditor técnico. Una prueba rápida: si mañana el comité pidiera los parámetros del modelo que asigna turnos, ¿quién los enviaría y cuántos días tardaría? Si la respuesta es "habría que preguntar a ciencia de datos", el canal no existe.
Ese canal solo funciona si el resto del equipo entiende lo que documenta. La IA sube el nivel mínimo de competencia de todo el equipo. Cada rol de producto necesita entender a grandes rasgos cómo funcionan los modelos: cuándo inventan, cómo se les dan instrucciones, cómo buscan en documentos, cómo se mide su calidad y qué riesgos éticos traen. Lo bastante para decidir, no para entrenar el modelo. Encima está la soltura con los datos, leer paneles de rendimiento y señales de deriva con la seguridad suficiente para discutirlos. Saber cuándo un resultado de una prueba A/B es real es una habilidad compartida.
Como la IA tiene coste variable, el PM sostiene a la vez la estrategia y la economía unitaria, y tiene que saber hacer la cuenta. Pongamos un asistente que resume expedientes: cuesta 0,003 euros por llamada y recibe 300.000 llamadas al mes: 900 euros.
El modelo más preciso cuesta ocho veces más, 7.200 euros al mes, por tres puntos de precisión. La pregunta es si esos tres puntos valen 6.300 euros mensuales. Si cada error obliga a un gestor a rehacer el expediente durante quince minutos, tres puntos son 9.000 expedientes corregidos menos al mes y la respuesta es sí. Si el error se detecta y corrige en segundos, la respuesta es no. Esa cuenta no la hace ciencia de datos por el PM.
El nivel de riesgo decide cuánto escrutinio se paga
Un marco de IA responsable convierte principios en comprobaciones: asigna a cada caso de uso un nivel de riesgo que determina el escrutinio, y la documentación de los conjuntos de datos y los registros de auditoría permiten revisar esos juicios después. En lugar de evaluar cada modelo a su manera, las empresas usan el mismo flujo para todos: ataques simulados (red teaming), conjuntos de referencia estables y pruebas antes y después del lanzamiento. Las políticas de aprobación definen quién firma y con qué evidencia.
La gobernanza tampoco acaba en el lanzamiento: cada modelo se registra y se supervisa, los cambios de datos o de comportamiento activan una revisión, y la retirada también necesita una salida documentada.
Un asistente que redacta borradores internos y otro que decide si alguien es apto para un crédito comparten flujo, pero no puerta de lanzamiento. El primero pasa con pruebas offline y un muestreo; el segundo exige red teaming dirigido, documentación de sesgo por segmento y una firma humana que responde ante el supervisor. Con cifras ilustrativas, la diferencia es tangible.
Si la puerta ligera cuesta dos días de trabajo y la pesada quince, una cartera de doce casos de uso tratados todos como críticos consume 180 días de evaluación al año; clasificando ocho como ligeros y cuatro como críticos, baja a 76. Equivocarse cuesta en las dos direcciones: cargar de controles los casos triviales ahoga la entrega, y tratar un caso sensible como trivial es justo la clase de decisión que reaparece en una auditoría. Por eso el nivel de riesgo se decide al plantear el problema, meses antes del lanzamiento.
El nivel de riesgo fija la puerta; la colaboración decide quién responde detrás de ella. La colaboración empieza antes que en un equipo de software. El científico de datos entra en el discovery cuando el problema todavía se está formulando, y el PM fija los criterios de evaluación antes de que el modelo exista, de modo que viabilidad y éxito se acuerdan de entrada. Si las cuatro disciplinas trabajan a la vez, en lugar de pasarse el testigo, hay menos desajustes y cada iteración se acorta.
La hoja de ruta se planifica por capas de capacidad, y el coste de inferencia y la latencia entran en ella antes de cualquier diseño. Como un sistema probabilístico no promete un resultado fijo, dirección y negocio necesitan un rango de comportamiento esperado y escenarios de riesgo; una fecha con una cifra promete lo que el modelo no puede garantizar.
Ese reparto a cuatro bandas tiene un modo de fallo propio. Cuando cuatro disciplinas comparten un resultado, la responsabilidad puede diluirse hasta que un modelo que se degrada en producción no tiene dueño: el científico de datos supone que MLOps vigila la deriva, MLOps supone que el PM decide cuándo reentrenar y el PM supone que la métrica sigue en verde porque nadie ha avisado. La colaboración estrecha no elimina la necesidad de un responsable único por cada resultado en producción; la hace más urgente.
El diseño se comprueba con tres números: la espera media en la cola de IA, por debajo de un trimestre; el porcentaje de modelos en producción con responsable nombrado, que debe ser el 100%; y los días que tarda en responderse una petición del comité de empresa. La salvaguarda es el coste de inferencia por usuario activo: si sube trimestre tras trimestre mientras la cola baja, la federación está comprando velocidad con margen.
¿Y si la empresa es demasiado pequeña para todo esto?
Las startups con un producto, un modelo y seis personas de tecnología suelen dudar de todo esto. Para ellas, plataforma, comité de riesgo y responsables separados suenan a ceremonia copiada de un banco. Tienen razón en parte: con un solo producto, un equipo multidisciplinar único, donde el mismo ingeniero hace ML y MLOps, entrega más rápido que cualquier topología, y montar una plataforma antes del segundo equipo de producto es pagar coordinación sin nada que coordinar.
Donde no tienen razón es en la responsabilidad, que no se reduce con el tamaño. Una startup de diez personas cuyo modelo prioriza candidatos responde ante el artículo 64.4 d) igual que una gran empresa. La versión mínima cabe en una página: un responsable por modelo, el registro de entradas y versión en cada decisión relevante y una forma de explicar los parámetros a quien los pida.
Para la empresa mediana, en cambio, el orden de las operaciones pesa más que cualquier decisión aislada. Acuerda el modelo operativo (quién es dueño de la plataforma, cómo funciona la gobernanza, qué métricas se definen de forma central) antes de ampliar la plantilla, porque una reorganización posterior cuesta mucho más que un plan de contratación pensado para encajar. En España, además, cada reorganización que cambie funciones o condiciones de trabajo tiene su propio procedimiento con la representación de los trabajadores, así que rehacer la estructura a mitad de año no es solo caro en tiempo.
Un orden razonable para los primeros noventa días, al pasar de proyectos sueltos de IA a una organización de producto:
- Mes uno, inventario honesto: qué modelos hay en producción, quién responde de cada uno, con qué datos se entrenaron y qué decisiones toman sobre clientes o empleados. Casi siempre aparecen dos o tres modelos sin dueño claro y alguno que nadie sabía que seguía activo.
- Mes dos, definiciones comunes: qué es una tarea completada, cómo se calcula el coste por inferencia, qué tasa de error es aceptable para cada nivel de riesgo.
- Mes tres, la primera frontera de plataforma, empezando por lo que ya comparten tres o más equipos, normalmente la observabilidad y el registro de modelos.
Con ese mapa delante, la siguiente contratación deja de ser una apuesta: se sabe qué hueco cubre y de qué resultado responderá.