Trabajar en un equipo de IA multidisciplinar: quién decide qué

Las dificultades de un proyecto de IA rara vez son solo técnicas. Suelen venir de decisiones tomadas por separado por funciones que no comparten la misma definición del problema, ni las mismas restricciones, ni el mismo horizonte.

Esta guía describe las decisiones reales de un equipo que construye un producto de IA, las fricciones más frecuentes y las prácticas que las reducen. No propone una organización ideal: los equipos eficaces se parecen poco entre sí.

Las funciones presentes y lo que aporta cada una

Un equipo de IA no es una suma de especialidades. Cada función aporta una restricción que las demás no ven desde su posición.

• Producto: arbitra valor, alcance y orden.
• Ingeniería IA: hace el sistema posible, fiable y explotable.
• Datos: condiciona lo que el sistema puede saber y hasta dónde puede llegar.
• Diseño / UX: determina qué entiende, controla y verifica la persona usuaria.
• Negocio: tiene la definición de lo que es correcto en el contexto real.
• Seguridad y cumplimiento: fijan los límites no negociables.

Esta agrupación solo sirve para describir las interfaces entre disciplinas. Según la organización, Data Scientist, ML Engineer y AI Engineer asumen responsabilidades distintas: metodología y evaluación por un lado, industrialización y explotación por otro, y el diseño de sistemas basados en modelos como tercer bloque. Reunirlos aquí en una misma columna no significa que sean intercambiables ni que uno solo de esos roles baste.

En una estructura pequeña una misma persona cubre varias de estas funciones. La cuestión no es el número de personas, sino que cada restricción tenga a alguien que la sostenga.

Las decisiones que hay que tomar y quién las asume

Una decisión mal atribuida cuesta más que una decisión imperfecta. La lista siguiente recoge las decisiones estructurantes de un producto de IA y cómo se toman en la práctica.

• El problema tratado — lo asumen Producto y Negocio, con ingeniería diciendo qué es realista.
• La definición de un buen resultado — la asumen Negocio y Producto, formalizada con datos e ingeniería.
• El alcance del sistema — lo asume Producto, restringido por los datos disponibles y los permisos.
• El enfoque técnico — lo asume ingeniería, arbitrado con Producto en coste y plazo.
• El protocolo de evaluación — lo asumen datos e ingeniería, alimentado con casos reales por Negocio.
• El nivel de control del usuario — lo asume Diseño, condicionado por el riesgo y por ingeniería.
• Las salvaguardas y límites de acción — los asumen Seguridad e ingeniería, arbitrados con Producto.
• El momento de la puesta en producción — lo asumen Producto e ingeniería, con acuerdo de Negocio.
• La retirada de un caso de uso — la asume Producto, a partir de lo que observa Negocio.

Tres decisiones que nadie toma en solitario

Unas pocas decisiones concentran la mayoría de los desacuerdos en un equipo de IA. Casi siempre tienen un responsable identificado, pero ninguna puede instruirse desde una sola disciplina: cada una aporta información que las demás no tienen.

¿La calidad es suficiente para lanzar?

No hay respuesta absoluta: depende del uso, de la población afectada y de lo que ocurre cuando el sistema se equivoca. No existe un umbral universal de calidad, y una cifra de evaluación nunca decide por sí sola.

• Product: el valor esperado, el alcance previsto, quién se ve realmente afectado y qué cuesta un lanzamiento limitado o aplazado.
• Data / ML / AI Engineering: resultados de evaluación, casos de fallo observados, estabilidad, restricciones técnicas, qué es observable en producción y en qué condiciones el sistema se puede explotar.
• UX / Research: qué entiende la persona usuaria del resultado, cuánta confianza le da, si puede detectar y corregir un error, y cómo se comporta de verdad ante una propuesta.
• Negocio / experto del dominio: qué calidad es realmente aceptable en ese contexto, qué excepciones importan y qué consecuencias operativas tiene un error no detectado.

La decisión rara vez es «lanzar o no»: es para quién, con qué alcance y con qué red de seguridad.

¿Automatizar o asistir?

Que una tarea sea técnicamente automatizable no significa que convenga automatizarla. El arbitraje se construye con unos pocos elementos concretos, y puede diferir entre casos de uso dentro de un mismo producto.

• La consecuencia de un error y si es reversible o no.
• Si alguien puede verificar el resultado con un esfuerzo razonable.
• La frecuencia de las excepciones y el juicio que exigen.
• La responsabilidad: quién responde del resultado una vez ejecutada la acción.
• El valor real de la automatización frente a una asistencia bien diseñada.

También aquí la respuesta se reparte: negocio dice qué provoca un error, ingeniería dice qué hace el sistema de forma estable, UX dice si la verificación es realista para la persona usuaria, y Product arbitra según el uso previsto.

¿Qué hacer cuando el sistema está incierto?

Un sistema probabilístico encuentra casos que trata mal. Lo que hace en esos momentos es una decisión de producto en sí misma, no un detalle de implementación. Una puntuación de confianza puede ayudar, pero no resuelve la cuestión: solo desplaza el umbral.

• Pedir información adicional antes de proponer nada.
• Mostrar la incertidumbre, siempre que sea realmente interpretable.
• Proponer un resultado exigiendo una validación explícita.
• Pasar a un tratamiento determinista o a una regla conocida.
• Escalar a una persona competente en ese caso.
• Negarse a actuar y decirlo con claridad.
• Permitir en todo momento que la persona retome el control.

Product decide qué promete el producto en esos casos, ingeniería y datos dicen qué es detectable y a qué coste, UX diseña lo que la persona ve y puede hacer, y negocio dice qué situaciones no toleran ninguna acción automática.

Un responsable no decide solo

Nombrar a un responsable evita la indecisión colectiva; no significa que esa persona tenga la información necesaria. Un equipo sano separa cuatro cosas: quién asume la decisión, qué expertises contribuyen, qué información falta todavía y si hace falta una validación antes de aplicarla.

No se trata de escribir una matriz de responsabilidades universal: el reparto cambia con el tamaño del equipo y la criticidad del producto. Lo que debe permanecer es que esas cuatro preguntas tengan una respuesta explícita.

Las fricciones recurrentes

Las mismas tensiones se repiten de un equipo a otro. Nombrarlas permite tratarlas como temas normales y no como conflictos personales.

La calidad frente al plazo

Un sistema puede ser suficiente para un primer uso restringido e insuficiente para un despliegue amplio. La fricción desaparece cuando el equipo separa explícitamente los dos niveles de exigencia en lugar de discutir una calidad abstracta.

La incertidumbre frente al compromiso de fecha

Un trabajo exploratorio no se planifica como un desarrollo conocido. Los equipos que lo resuelven dividen el tema en preguntas por resolver, con fecha para la respuesta y no para el resultado final.

El dato disponible frente al dato necesario

Muchas funcionalidades fallan no por el modelo sino por datos ausentes, mal etiquetados o cuyo uso no está autorizado. Esto pertenece al encuadre, no al descubrimiento a mitad de camino.

La demostración frente a la producción

Un prototipo convincente dice muy poco del comportamiento en producción. Un equipo sano separa lo que se ha mostrado de lo que se ha medido y no toma una demostración por una prueba.

La evaluación huérfana

Cuando nadie es dueño de la evaluación, se hace tarde, por la persona peor situada y sobre casos demasiado fáciles. Es probablemente la fricción más cara y más discreta.

Convertir un desacuerdo en una decisión instruida

Tomemos la fricción más frecuente: Product quiere lanzar y la evaluación sigue mostrando fallos serios. Mientras la discusión enfrenta dos opiniones, no avanza. Avanza en cuanto se reformula como una hipótesis que verificar. La secuencia siguiente es un escenario pedagógico, no un procedimiento.

1. 1

   Hipótesis

   paso 1

   Los errores restantes se concentran en un tipo de caso identificable y no en el conjunto del uso.

2. 2

   Riesgo

   paso 2

   Si esos casos afectan a una población sensible o a una acción difícil de deshacer, ser poco frecuentes no basta para aceptarlos.

3. 3

   Información que falta

   paso 3

   Se desconoce su frecuencia real en uso y, sobre todo, si la persona usuaria puede detectar el error antes de actuar.

4. 4

   Prueba

   paso 4

   Un análisis dirigido de los fallos por tipo de caso, observación de usuarios en esas situaciones concretas y la instrumentación necesaria para contarlos una vez en producción.

5. 5

   Decisión

   paso 5

   Según lo que muestre la prueba: lanzar con alcance restringido, modificar el producto para hacer visible el error, mantener una validación humana en esos casos o aplazar.

El buen desenlace no se conoce de antemano ni se generaliza: lo que se transpone es el paso de un choque de opiniones a una información que falta y que el equipo decide ir a buscar.

Qué mejora de verdad la colaboración

1. 1

   Escribir la definición de buen resultado

   en el encuadre

   Una frase, validada por Negocio, que diga qué debe producir el sistema y qué no tiene que hacer. Sirve de referencia en todas las discusiones posteriores.

2. 2

   Reunir un conjunto de casos reales

   en el encuadre

   Un conjunto de casos del terreno suficiente para cubrir las situaciones difíciles, las excepciones y los casos fuera de alcance relevantes vale más que un documento largo de requisitos.

3. 3

   Separar demostración y medida

   de forma continua

   Mostrar un resultado sirve para alinear; decidir exige una medida sobre casos que nadie eligió para la ocasión.

4. 4

   Hacer visibles las restricciones

   de forma continua

   Latencia, coste, permisos, frescura de los datos: exponerlos pronto evita decisiones de producto invalidadas después.

5. 5

   Nombrar un responsable por decisión

   en cada tema

   No un comité: una persona que decide tras escuchar y explica el criterio elegido.

6. 6

   Revisar juntos los fallos

   periódicamente

   Una revisión corta con Negocio sobre unos pocos fallos reales orienta mejor el trabajo que un cuadro de mando.

Caso pedagógico: decidir el lanzamiento de una funcionalidad de IA

Escenario ficticio, construido para mostrar cómo decide un equipo. No describe ningún producto real y no incluye cifras de forma deliberada.

Una funcionalidad analiza información de negocio y propone una acción a la persona usuaria. En las situaciones habituales, el equipo considera la calidad satisfactoria. En los casos ambiguos o incompletos, varía mucho más. La pregunta no es «¿está listo?», sino «¿qué lanzamos, para quién y en qué condiciones?».

• Product: identifica los casos de uso donde la funcionalidad aporta algo real y acepta reducir el alcance inicial en vez de cubrir todas las situaciones.
• Data / ML / AI Engineering: muestra dónde cae la calidad, dice qué es detectable automáticamente, qué resulta caro de vigilar y qué habrá que observar una vez en producción.
• UX / Research: diseña cómo se presenta la propuesta, comprueba que la persona pueda cuestionarla y avisa cuando la formulación induce una confianza excesiva.
• Negocio / experto del dominio: indica qué acciones no deben ejecutarse nunca sin revisión y qué errores se corrigen sin consecuencias.

Con esos elementos, el equipo puede decidir qué se automatiza, qué queda como recomendación y qué exige validación humana. Los casos ambiguos pueden, según el contexto, pedir información adicional, devolver al proceso habitual o no proponer nada.

El desenlace no tiene por qué ser binario. Un lanzamiento limitado a unos pocos equipos, una automatización restringida a los casos mejor cubiertos, una validación humana mantenida en el resto, más instrumentación antes de ampliar o una nueva evaluación sobre los casos difíciles: todas son decisiones razonables. Lo importante no es la opción elegida aquí, sino que cada disciplina haya aportado la información que tenía y que alguien haya decidido con un criterio explícito.

Qué postura adoptar según el rol

Entender las restricciones de los demás no significa hacer su trabajo. La postura útil consiste en saber qué limita a las otras funciones para formular las propias peticiones de forma aprovechable.

• Producto: formular una necesidad como una decisión a mejorar, no como una funcionalidad a entregar.
• Ingeniería: explicitar las restricciones en términos de impacto de producto, no solo técnicos.
• Datos: decir pronto qué no permiten los datos y en qué condiciones eso cambiaría.
• Diseño: traducir la incertidumbre del sistema en elementos de interfaz comprensibles.
• Negocio: aportar casos reales en lugar de reglas generales.
• Seguridad: distinguir los límites no negociables de las recomendaciones, para evitar el bloqueo total.

Esta competencia de colaboración rara vez aparece escrita en un perfil, aunque se ve mucho en entrevista: se nota en cómo se cuenta una decisión, sus restricciones y su criterio.

• AI Engineering
• Producto IA
• Evaluación