Equipos de Datos de IA Cross-Funcionales: Ingenieros de ML + Expertos de Dominio + Cumplimiento

La mayoría de los esfuerzos de preparación de datos de IA empresarial están dotados por una sola función: el equipo de ingeniería de ML. Ellos diseñan el pipeline, parsean los documentos, etiquetan los datos (frecuentemente mal, porque carecen de expertise de dominio), verifican la calidad (solo contra métricas técnicas), y exportan el dataset. Los expertos de dominio son consultados ocasionalmente. Cumplimiento revisa la salida una vez, al final, y frecuentemente solicita cambios que requieren retrabajo.

Este enfoque de función única produce tres fracasos predecibles:

Datasets técnicamente correctos pero inexactos en dominio. Un ingeniero de ML etiquetando registros médicos identificará correctamente que "SOB" es una abreviatura pero puede no saber que significa "shortness of breath" (dificultad para respirar) en contexto clínico. Un modelo entrenado con estas etiquetas será técnicamente funcional pero clínicamente incorrecto.

Etiquetas precisas que no escalan. Cuando se traen expertos de dominio, producen etiquetas de alta calidad pero no pueden sostener el volumen necesario. Un cardiólogo que etiqueta 20 ejemplos un martes y luego desaparece por tres semanas no es una operación de datos escalable.

Revisiones de cumplimiento que fuerzan retrabajo. Cuando el oficial de cumplimiento revisa el dataset terminado y descubre que la PII no fue manejada correctamente, o que la documentación de linaje de datos está incompleta, todo el pipeline debe re-ejecutarse. Este retrabajo típicamente cuesta 3-6 semanas.

La solución no son entregas secuenciales entre funciones — es un equipo cross-funcional donde ingenieros de ML, expertos de dominio y oficiales de cumplimiento trabajan en el pipeline de preparación de datos simultáneamente, con roles definidos y herramientas apropiadas.

Los Tres Roles

Ingeniero de ML: Arquitecto del Pipeline

El rol del ingeniero de ML en preparación de datos es arquitectura y automatización, no trabajo manual con datos.

Responsabilidades:

• Diseñar el pipeline de preparación de datos: ingesta → parseo → etiquetado → calidad → exportación
• Configurar métricas y umbrales de calidad (objetivos de acuerdo inter-anotador, ratios de deduplicación, requisitos de balance de clases)
• Configurar automatización: ingesta automatizada de fuentes de datos, verificaciones de calidad automatizadas en datos entrantes, calendarios de exportación automatizados
• Construir y mantener configuraciones de exportación que produzcan datasets listos para entrenamiento en el formato requerido
• Monitorear la salud del pipeline: throughput, tasas de error, latencia de procesamiento
• Analizar métricas de calidad e identificar problemas sistemáticos (patrones de desacuerdo entre anotadores, shifts de distribución de datos)

Lo que NO debería hacer:

• Etiquetar datos. Carece de expertise de dominio y su tiempo se aprovecha mejor en ingeniería.
• Definir guías de etiquetado. No conoce el dominio lo suficiente.
• Tomar decisiones de cumplimiento. No conoce los requisitos regulatorios.

Asignación de tiempo: 30-40% del tiempo de proyecto de un ingeniero de ML debería dedicarse a arquitectura y monitoreo del pipeline. El otro 60-70% va a entrenamiento de modelos, evaluación y despliegue. Si está gastando más del 40% en trabajo de pipeline de datos, el pipeline necesita más automatización.

Experto de Dominio: Autoridad de Precisión

El rol del experto de dominio es asegurar que el dataset sea correcto según los estándares de su profesión.

Responsabilidades:

• Escribir guías de etiquetado que reflejen estándares profesionales y conocimiento de dominio
• Etiquetar ejemplos — típicamente 20-30 minutos por día, produciendo 15-30 ejemplos etiquetados por sesión
• Revisar una muestra de las etiquetas de otros anotadores para calidad (si hay múltiples anotadores involucrados)
• Identificar casos límite que el pipeline manejó incorrectamente — tipos de documentos, terminología o escenarios que los pasos automatizados obtuvieron mal
• Validar el dataset final contra estándares profesionales: "¿Confiaría en un modelo entrenado con estos datos para manejar mis casos?"

Lo que NO debería hacer:

• Configurar el pipeline. No necesita saber cómo se parsean los documentos o cómo se exportan los datos.
• Definir métricas de calidad. Debería validar que las métricas que eligió el ingeniero de ML son significativas, pero definir umbrales de kappa de Cohen no es su responsabilidad.
• Manejar documentación de cumplimiento. Produce los datos etiquetados; cumplimiento rastrea la gobernanza.

Asignación de tiempo: 20-30 minutos por día durante fases activas de etiquetado. Sesiones periódicas de revisión (1-2 horas por semana) durante fases de validación de calidad. Esto es sostenible para profesionales ocupados y produce volumen suficiente para la mayoría de los proyectos.

Oficial de Cumplimiento: Guardián de la Gobernanza

El rol del oficial de cumplimiento es asegurar que el pipeline de preparación de datos cumpla con los requisitos regulatorios y de política organizacional.

Responsabilidades:

• Verificar que el rastro de auditoría esté completo: el origen de cada documento, cada transformación, cada decisión de etiquetado está rastreada
• Revisar políticas de gobernanza de datos: retención de datos, control de acceso, derechos de eliminación, restricciones de transferencia transfronteriza
• Asegurar que el manejo de PII/PHI cumpla con las regulaciones aplicables (GDPR, HIPAA, Artículo 10 del EU AI Act)
• Revisar y aprobar la documentación de linaje de datos antes de que el dataset se use para entrenamiento
• Validar controles de acceso: quién puede ver qué datos, quién puede modificar etiquetas, quién puede exportar datasets

Lo que NO debería hacer:

• Etiquetar datos. No tiene expertise de dominio.
• Diseñar el pipeline. Especifica requisitos; el ingeniero de ML los implementa.
• Esperar hasta el final para revisar. Para entonces, los problemas de cumplimiento están incrustados en todo el dataset y la remediación es costosa.

Asignación de tiempo: 2-4 horas por semana durante preparación activa de datos. Mayor durante la configuración inicial del pipeline (cuando se están configurando las políticas de gobernanza) y durante la revisión final antes de la exportación del dataset.

Opciones de Estructura de Equipo

Pod Integrado (Recomendado para 1-3 Proyectos)

Un solo equipo cross-funcional dedicado a un proyecto de IA específico. El pod incluye:

• 1 ingeniero de ML (tiempo completo en el proyecto)
• 2-3 expertos de dominio (tiempo parcial, 30 minutos/día)
• 1 oficial de cumplimiento (tiempo parcial, compartido entre 2-3 pods)

Ventajas: Comunicación estrecha, toma de decisiones rápida, responsabilidad clara. El equipo se sienta junto (física o virtualmente) y resuelve problemas en tiempo real.

Desventajas: No escala más allá de 3-4 proyectos sin duplicar headcount de ingenieros de ML y cumplimiento.

Modelo Matricial (Para 4-10 Proyectos)

Equipos funcionales (ingeniería de ML, expertise de dominio, cumplimiento) contribuyen miembros a proyectos de preparación de datos. Un ingeniero de ML podría soportar dos proyectos de preparación de datos simultáneamente.

Ventajas: Uso más eficiente del talento especializado. Los ingenieros de ML y oficiales de cumplimiento se comparten entre proyectos.

Desventajas: Atención dividida. El ingeniero de ML soportando dos proyectos prioriza uno, y el otro se estanca. Requiere gestión de proyecto fuerte para prevenir esto.

Mitigación: Escalonar las fases de proyecto. Si el Proyecto A está en la fase de etiquetado (baja demanda de ingeniero de ML) mientras el Proyecto B está en configuración de pipeline (alta demanda de ingeniero de ML), el mismo ingeniero puede soportar ambos.

Hub-and-Spoke (Para Más de 10 Proyectos u Operaciones Continuas)

Un equipo central de operaciones de datos (hub) de 2-4 ingenieros de ML y 1 oficial de cumplimiento mantiene la plataforma de preparación de datos y maneja la arquitectura del pipeline. Contribuyentes expertos de dominio (spokes) de toda la organización participan en etiquetado y revisión por proyecto.

Ventajas: Escala a muchos proyectos. El equipo hub desarrolla expertise profundo en preparación de datos. Los expertos de dominio se traen solo cuando su conocimiento específico es necesario.

Desventajas: El equipo hub puede convertirse en un cuello de botella. Los expertos de dominio sienten menos ownership porque son periféricos al proceso.

Mitigación: Etiquetado autoservicio. El equipo hub configura los proyectos y configura las verificaciones de calidad, luego los expertos de dominio acceden a sus colas de etiquetado independientemente sin involucrar al equipo hub.

Cadencia de Comunicación

Los standups diarios para equipos de preparación de datos son un desperdicio. El trabajo de preparación de datos es en gran parte independiente — los anotadores etiquetan ejemplos, el ingeniero de ML monitorea la calidad, el oficial de cumplimiento revisa documentación. No hay suficiente que discutir diariamente.

Sincronización semanal (30 minutos): Los tres roles se reúnen una vez por semana para revisar:

• Progreso de etiquetado: ejemplos etiquetados esta semana, tendencia de métricas de calidad
• Problemas del pipeline: errores de parseo, fallas de verificación de calidad, preguntas de anotadores
• Estado de cumplimiento: cualquier nuevo requisito, completitud del rastro de auditoría
• Prioridades de la próxima semana

Canal de revisión asíncrono: Un canal de Slack/Teams para preguntas en tiempo real. Los expertos de dominio publican ejemplos ambiguos ("¿Cómo debería etiquetar esto?"). El ingeniero de ML publica alertas de métricas de calidad. El oficial de cumplimiento señala brechas de documentación.

Retrospectiva mensual (1 hora): Revisar el proceso general de preparación de datos. ¿Qué funciona? ¿Qué es lento? ¿Dónde están los cuellos de botella? Aquí es donde se identifican y planifican mejoras de proceso.

Resolución de Conflictos

Los tres roles tienen tensiones naturales que requieren mecanismos explícitos de resolución.

"Más Datos" vs. "Minimizar Datos"

El ingeniero de ML quiere más ejemplos de entrenamiento para mejor rendimiento del modelo. El oficial de cumplimiento quiere minimizar la recolección y retención de datos. Ambos tienen razón dentro de su dominio.

Resolución: Define el dataset mínimo viable — el dataset más pequeño que logra el objetivo de rendimiento. Recopila esa cantidad, más un 20% de buffer para filtrado de calidad. Documenta la justificación del volumen recolectado. Esto satisface las necesidades de rendimiento del ingeniero de ML mientras cumple los requisitos de minimización de datos del oficial de cumplimiento.

"Velocidad" vs. "Calidad"

El ingeniero de ML quiere moverse rápido — "etiquetemos 1,000 ejemplos esta semana y comencemos a entrenar." El experto de dominio insiste en revisión cuidadosa — "necesito pensar en cada ejemplo."

Resolución: Sesiones de etiquetado con tiempo limitado (20 minutos/día) pero umbrales de calidad que deben cumplirse antes de comenzar el entrenamiento. Esto previene ambos extremos: el ingeniero de ML no puede apresurar el etiquetado más allá del umbral de calidad, y el experto de dominio no puede retrasar el proyecto indefinidamente gastando 15 minutos por ejemplo.

"Documentación Completa" vs. "Solo Lánzalo"

El oficial de cumplimiento quiere documentación completa de cada decisión de manejo de datos. El ingeniero de ML quiere entrenar el modelo e iterar.

Resolución: Construye la documentación en las herramientas, no en un proceso separado. Si la plataforma registra automáticamente quién etiquetó qué, cuándo y cómo fluyeron los datos a través del pipeline, la documentación de cumplimiento se genera como subproducto de hacer el trabajo — no como un paso adicional que crea fricción.

Escalando el Modelo

A medida que una organización madura, el modelo de equipo cross-funcional evoluciona:

Etapa 1 (Primer proyecto): Colaboración cross-funcional ad-hoc. El ingeniero de ML contacta a un experto de dominio dispuesto. Cumplimiento revisa al final. Esto funciona una vez.

Etapa 2 (2-5 proyectos): Pods integrados formalizados con roles definidos y cadencia de comunicación. Cumplimiento está involucrado desde el inicio. Las guías de etiquetado están documentadas y se reutilizan.

Etapa 3 (5-15 proyectos): Modelo hub-and-spoke. Equipo central de data ops, red de contribuyentes expertos de dominio, oficial de cumplimiento compartido. Flujos de trabajo y plantillas estandarizados.

Etapa 4 (Más de 15 proyectos): Preparación de datos como servicio. El equipo central opera la plataforma, gestiona estándares de calidad y proporciona capacidades de autoservicio para que los equipos de proyecto configuren sus propios flujos de trabajo de preparación de datos dentro de guardarraíles de gobernanza.

Cada etapa requiere diferentes capacidades de herramientas. La Etapa 1 puede sobrevivir con herramientas básicas. Las Etapas 3-4 requieren una plataforma con controles de acceso basados en roles, plantillas de flujos de trabajo, monitoreo automatizado de calidad y reportes de cumplimiento — todo en un solo sistema.

Ertas Data Suite soporta flujos de trabajo basados en roles para los tres roles. Los ingenieros de ML configuran pipelines, métricas de calidad y configuraciones de exportación. Los expertos de dominio acceden a una interfaz de etiquetado simplificada diseñada para usuarios no técnicos — sin código, sin terminal, sin configuración. Los oficiales de cumplimiento acceden a rastros de auditoría, informes de linaje de datos y dashboards de control de acceso. Cada rol ve solo lo que necesita, con permisos apropiados. La plataforma corre on-premise, proporcionando las garantías de residencia de datos que los oficiales de cumplimiento requieren.

---

Lectura Adicional

• The Data Preparation Gap in ML Teams — Por qué los equipos de ML luchan con la preparación de datos y cómo contribuye la estructura organizacional.
• Domain Experts Are Locked Out of AI Data — Cómo las herramientas actuales excluyen a las personas cuyo conocimiento la IA más necesita.
• The Enterprise AI Data Preparation Guide — Un recorrido completo del ciclo de vida de preparación de datos para proyectos de IA empresarial.