
El cuello de botella de anotación: cuando solo 3 personas en tu organización pueden etiquetar datos
La mayoría de las empresas tienen 2-3 ingenieros de ML que pueden operar herramientas de anotación. Mientras tanto, docenas de expertos de dominio están inactivos con el conocimiento necesario para etiquetas de alta calidad. Este cuello de botella está matando los plazos de IA.
Este es un escenario que se repite en casi todos los proyectos de IA empresarial. El equipo de ML necesita 10,000 ejemplos etiquetados. La organización emplea a 40 personas con la experiencia de dominio para etiquetar con precisión. Pero las herramientas de anotación requieren Python, Docker o acceso a plataformas en la nube. Entonces el etiquetado real recae en 2-3 ingenieros de ML que tienen que interpretar conocimiento de dominio que no poseen.
Los 40 expertos de dominio tienen el conocimiento. Los 3 ingenieros de ML tienen el acceso a las herramientas. El proyecto toma 4 meses en lugar de 3 semanas.
Este es el cuello de botella de anotación, y es una de las razones más subestimadas por las que los proyectos de IA empresarial incumplen plazos, exceden presupuestos y producen resultados decepcionantes.
Cómo se forma el cuello de botella
El cuello de botella de anotación no se trata de esfuerzo o voluntad. Se trata de accesibilidad a las herramientas. Así es como se desarrolla típicamente:
Fase 1: Selección de herramientas. El equipo de ML evalúa plataformas de anotación. Eligen basándose en características, calidad de API, integración con modelos y formatos de exportación. La usabilidad para usuarios no técnicos es una consideración secundaria, si es que se considera.
Fase 2: Configuración. La herramienta elegida requiere despliegue en la nube o auto-hospedaje. El despliegue en la nube significa subir datos empresariales potencialmente sensibles a un servidor de terceros. El auto-hospedaje significa Docker, proxies reversos, sistemas de autenticación y mantenimiento continuo. De cualquier manera, el equipo de ML es dueño de la infraestructura.
Fase 3: Intento de incorporación. El equipo intenta incorporar a los expertos de dominio. Esto requiere crear cuentas, explicar la interfaz, configurar permisos y a menudo escribir scripts personalizados para cargar formatos de datos específicos del dominio. Después de 2-3 sesiones de capacitación, la adopción se estanca. Los expertos de dominio tienen sus propios trabajos que hacer. Aprender una nueva herramienta técnica no está en su flujo de trabajo.
Fase 4: El equipo de ML etiqueta. Los plazos se acercan. Los ingenieros de ML comienzan a etiquetar datos ellos mismos, consultando a los expertos de dominio por Slack, correo electrónico o reuniones programadas cuando encuentran ejemplos ambiguos. La carga de trabajo de anotación ahora compite con sus responsabilidades de ingeniería.
Este es el cuello de botella. Y tiene tres efectos compuestos.
Efecto 1: El teléfono descompuesto
Cuando un ingeniero de ML encuentra un ejemplo ambiguo, le pregunta a un experto de dominio por orientación. Esto crea una cadena de comunicación que degrada la calidad de la información en cada paso.
Considera un proyecto de procesamiento de reclamos de seguros. El ingeniero de ML ve una descripción de reclamo y necesita clasificar el tipo de daño. Le envía un mensaje al suscriptor: "¿Esto es daño por agua o daño estructural?" El suscriptor responde: "Es daño por agua que causó daño estructural — típicamente lo clasificarías basado en la causa próxima, que es agua, pero si el daño estructural excede el 40% del valor total del reclamo, algunos aseguradores lo reclasifican."
El ingeniero de ML ahora tiene que traducir esa lógica de dominio matizada en una sola etiqueta. Elige "daño por agua" y sigue adelante. El matiz — el umbral del 40%, la variación específica del asegurador — se pierde.
Este es el efecto de teléfono descompuesto. El conocimiento de dominio se comprime a través de un canal de comunicación que no puede transportar toda su complejidad. A lo largo de miles de ejemplos, estas compresiones se acumulan en errores sistemáticos de etiquetado.
En nuestra experiencia trabajando con equipos empresariales, el etiquetado por teléfono descompuesto introduce un 5-12% de errores adicionales de etiquetado comparado con el etiquetado directo de expertos. En un dataset de 10,000 ejemplos, eso es 500-1,200 ejemplos con etiquetas degradadas — más que suficiente para reducir mediblemente el rendimiento del modelo.
Efecto 2: Colapso de rendimiento
La matemática es simple. Si tu organización tiene 3 ingenieros de ML que pueden operar las herramientas de anotación, y cada uno puede etiquetar aproximadamente 200 ejemplos por día mientras también manejan su trabajo de ingeniería, tu rendimiento máximo es de 600 ejemplos etiquetados por día.
Si necesitas 10,000 ejemplos etiquetados, eso son aproximadamente 17 días hábiles — más de 3 semanas calendario — asumiendo que los ingenieros de ML no hagan nada más.
En realidad, también están construyendo pipelines, entrenando modelos, depurando infraestructura y asistiendo a reuniones. El rendimiento realista es más cercano a 50-100 ejemplos etiquetados por ingeniero por día. A ese ritmo, 10,000 ejemplos toman 5-10 semanas.
Ahora considera la alternativa. Si 20 expertos de dominio pudieran etiquetar 100 ejemplos cada uno por día — lo cual es conservador, ya que el etiquetado es más rápido cuando entiendes el dominio — el mismo dataset se completa en 5 días hábiles.
La diferencia de rendimiento no es incremental. Es un orden de magnitud. Y se propaga por todo el cronograma del proyecto. Cada iteración del modelo, cada revisión de esquema, cada actualización de datos espera a las mismas 3 personas.
Efecto 3: Destrucción de cronograma
Los proyectos de IA empresarial típicamente siguen un ciclo: etiquetar datos, entrenar modelo, evaluar, identificar brechas, etiquetar más datos, reentrenar. Cada ciclo idealmente toma 1-2 semanas. La mayoría de los proyectos necesitan 3-5 ciclos para alcanzar calidad de producción.
Con el cuello de botella de anotación, cada ciclo se extiende a 4-8 semanas. Un proyecto que debería tomar 3-4 meses toma 9-12 meses. Durante esos meses extra, los requisitos cambian, los stakeholders pierden confianza, los presupuestos se cuestionan y las prioridades competidoras absorben la atención del equipo de ML.
Rastreamos cronogramas en 15 proyectos de IA empresarial en 2025. Los que tenían cuellos de botella de anotación — donde menos de 5 personas podían operar las herramientas de etiquetado — promediaron 11.2 meses desde el inicio hasta el despliegue en producción. Los que permitían a los expertos de dominio etiquetar directamente promediaron 4.8 meses. Mismos tipos de proyectos, volúmenes de datos similares, arquitecturas de modelo comparables.
La diferencia de 6 meses fue casi completamente atribuible al rendimiento de etiquetado y la velocidad de iteración.
Por qué este cuello de botella es invisible
El cuello de botella de anotación rara vez aparece en planes de proyecto o retrospectivas. He aquí por qué:
Parece un problema de ingeniería. Cuando el proyecto está atrasado, el síntoma visible es "el modelo no es suficientemente preciso" o "necesitamos más datos de entrenamiento." La causa raíz — que el rendimiento de etiquetado está limitado por la accesibilidad de las herramientas — se esconde detrás de estos síntomas.
Nadie rastrea la velocidad de etiquetado. La mayoría de los equipos rastrean precisión del modelo, tiempo de entrenamiento y latencia de inferencia. Casi nadie mide ejemplos-etiquetados-por-día o tiempo-por-ejemplo-etiquetado. Sin estas métricas, el cuello de botella es invisible.
El equipo de ML absorbe el costo. Los ingenieros de ML típicamente no escalan "pasé el 60% de mi semana etiquetando datos" como un riesgo del proyecto. Lo ven como parte del trabajo. El costo organizacional — ingenieros senior haciendo trabajo que los expertos de dominio podrían hacer mejor y más rápido — pasa desapercibido.
Rompiendo el cuello de botella
La solución no es contratar más ingenieros de ML. No es comprar una plataforma de anotación más costosa. Es eliminar las barreras técnicas que impiden que los expertos de dominio etiqueten directamente.
Esto requiere un conjunto específico de capacidades:
Despliegue sin infraestructura. La herramienta de etiquetado debe instalarse y ejecutarse sin intervención de TI, Docker o configuración en la nube. Si requiere un ticket al equipo de infraestructura, la adopción se estancará.
Procesamiento de datos local. Los datos empresariales son sensibles. Registros de salud, documentos legales, datos financieros, especificaciones de ingeniería. La herramienta debe trabajar con archivos en la máquina del usuario, sin que los datos salgan del perímetro de la organización.
Definición visual de esquemas. Los expertos de dominio deberían definir cómo se ven las etiquetas — categorías, jerarquías, relaciones — a través de una interfaz visual, no un archivo de configuración JSON.
Formatos de exportación estándar. La salida debe integrarse con pipelines de ML existentes sin scripts de conversión personalizados.
Ertas Data Suite fue diseñado para eliminar el cuello de botella de anotación. Es una aplicación de escritorio nativa que los expertos de dominio instalan y ejecutan como cualquier otro software en su máquina. No hay Docker, no hay subida a la nube, no hay requisito de Python. Los expertos de dominio apuntan a sus datos locales, configuran esquemas de etiquetado visualmente y comienzan a producir datasets etiquetados.
El resultado: en lugar de 3 ingenieros de ML etiquetando datos que no entienden completamente, 30 expertos de dominio etiquetan datos con los que trabajan todos los días. El cuello de botella desaparece. Proyectos que tomaban 11 meses toman 5.
Turn unstructured data into AI-ready datasets — without it leaving the building.
On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.
Keep reading

Why Domain Experts — Not ML Engineers — Should Own Data Labeling
The biggest quality bottleneck in enterprise AI isn't the tools — it's that the people with actual domain knowledge are locked out of the labeling process. Here's why that needs to change.

The Data Preparation Gap: Why ML Teams Spend 80% of Time Before Training Starts
Why the 60-80% data preparation statistic persists — fragmented tooling, domain expert exclusion, missing audit trails, and the structural underinvestment in purpose-built data prep tools.

AI Data Quality Is a Domain Problem, Not a Code Problem
Data quality in AI is fundamentally about domain knowledge, not engineering. Perfect pipelines produce garbage if labeling criteria are wrong. The best dedup can't tell which version to keep.