Trabajos de anotación de datos: en qué consiste etiquetar y revisar respuestas de IA

Llevo meses trabajando como anotador de IA, revisando respuestas de modelos para entrenarlos, y al mismo tiempo construyo productos con LLMs. Eso me deja ver el proceso desde los dos lados: como quien produce el dato de entrenamiento y como quien consume el modelo resultante. La anotación de datos es exactamente eso: el trabajo de producir los ejemplos con los que se entrena y evalúa un modelo —etiquetar textos e imágenes, escribir respuestas de referencia y comparar respuestas generadas por el propio modelo—. En este artículo explico en qué consisten estos trabajos, cómo se conectan con el entrenamiento y qué separa a un anotador valioso de uno prescindible.

En este artículo:

• Fundamentos — Qué es la anotación de datos · SFT y RLHF: dónde entra el humano
• El trabajo — Revisar respuestas de IA · Tareas de control y consenso
• Contexto — Plataformas, requisitos y pago · Calidad sobre volumen

Qué es la anotación de datos y por qué existe como trabajo

Un modelo de machine learning aprende de ejemplos. Para que distinga spam de correo legítimo, alguien marcó miles de correos como “spam” o “no spam”. Para que un auto autónomo reconozca peatones, alguien dibujó cajas alrededor de peatones en millones de fotogramas. Ese “alguien” es el anotador de datos, y su producto de trabajo es la etiqueta: el dato que le dice al modelo cuál era la respuesta correcta.

Esto existe como trabajo remunerado porque los modelos necesitan volúmenes enormes de ejemplos correctos, y producir un ejemplo correcto requiere juicio humano. La industria lleva más de una década operando para visión por computadora y voz, pero los LLMs cambiaron el perfil de la tarea: ya no se trata solo de marcar categorías, sino de escribir y juzgar texto. De ahí salen los puestos que hoy se anuncian como “AI trainer” o “response evaluator”. Las tareas más comunes:

Las tres primeras filas son la anotación clásica: instrucciones cerradas y volumen alto. Las cuatro últimas crecieron con los LLMs y exigen leer con atención, verificar hechos y escribir; por eso se pagan mejor y se asignan con filtros más exigentes.

Dónde entra el humano: SFT y RLHF

Para entender qué compra una empresa de IA cuando paga anotación, ayuda ver el pipeline de entrenamiento completo:

Texto masivo (web, libros, código)
   │
   ▼
Preentrenamiento ──► modelo base: completa texto, no conversa
   │
   ▼
SFT ◄── humanos escriben la respuesta ideal (demostraciones)
   │
   ▼
RLHF ◄── humanos comparan respuestas A vs B (preferencias)
   │
   ▼
Modelo final: el que responde en el chat

El preentrenamiento no usa anotadores: el modelo aprende a predecir texto sobre corpus masivos, y el resultado completa frases pero no sabe conversar.

El SFT (fine-tuning supervisado) es la primera fase con humanos: personas escriben la respuesta ideal a miles de prompts y el modelo aprende a imitarlas. Aquí el anotador no etiqueta, redacta.

El RLHF (aprendizaje por refuerzo con retroalimentación humana) es donde entra la revisión de respuestas, y en palabras simples funciona así: el modelo genera dos o más respuestas al mismo prompt y una persona elige la mejor. Con miles de esas elecciones se entrena un segundo modelo —el reward model— cuya única función es predecir qué respuesta preferiría un humano, y ese segundo modelo guía el ajuste final del principal. Cuando un revisor marca “A es mejor que B”, está fabricando la señal con la que el modelo aprende qué significa “mejor”.

Además del entrenamiento, hay trabajo humano en la evaluación continua: probar el modelo contra rúbricas y buscarle fallos antes y después de publicarlo.

En qué consiste revisar respuestas de IA

Es la tarea que hago yo mismo como anotador. El flujo típico:

Prompt
   │
   ▼
El modelo genera 2+ respuestas
   │
   ▼
El revisor aplica la rúbrica
   │
   ├── ¿Es correcta? (verificación de hechos)
   ├── ¿Sigue las instrucciones del prompt?
   ├── ¿Es segura? (sin contenido dañino)
   └── ¿Está bien escrita? (claridad, formato)
   │
   ▼
Elige la mejor + escribe la justificación

La unidad de trabajo es el par de preferencia: el prompt, las respuestas candidatas, la elección y la justificación. Como dato, se parece a esto:

{
  "prompt": "Explica qué es una API a alguien sin experiencia técnica",
  "response_a": "…texto generado por el modelo A…",
  "response_b": "…texto generado por el modelo B…",
  "choice": "A",
  "margin": "clearly_better",
  "rationale": "A responde sin jerga y con un ejemplo correcto; B usa términos que el prompt pedía evitar y contiene un dato incorrecto sobre HTTP."
}

Tres cosas definen si el trabajo está bien hecho. Verificar, no asumir: una respuesta puede sonar segura y estar equivocada, así que los datos comprobables (fechas, cifras, afirmaciones técnicas) se verifican antes de puntuar. Puntuar contra la rúbrica, no contra el gusto: si la guía del proyecto dice que seguir las instrucciones del prompt pesa más que el estilo, una respuesta elegante que ignora una instrucción pierde. Y justificar por escrito: “A es mejor” vale poco; “B contiene un error factual en la segunda cifra y no respeta el formato pedido” es una decisión auditable y, en muchos proyectos, parte del dato que se entrena.

La misma revisión la hago en pequeño al operar mis productos: reviso muestras de salidas en mi pipeline de routing de modelos y uso un evaluador que decide si el código generado pasa o no. Cambia la escala y el destino: en un producto revisas decenas de salidas para operarlo; como anotador revisas cientos para entrenar el próximo modelo.

Revisar muestras a mano fue lo que destapó, en mi propio pipeline, que muchos “fallos” del modelo barato eran errores de formato y no de calidad. Ese es exactamente el tipo de juicio que hace un revisor de respuestas de IA: distinguir por qué una salida está mal, no solo que está mal.

Cómo te evalúan: tareas de control y consenso

Las plataformas no confían en el juicio de un solo anotador, y sus dos mecanismos estándar definen cómo te miden a ti:

• Tareas de control: tareas con respuesta conocida que se mezclan con las normales sin avisar. Si las fallas, tu precisión medida baja y pierdes acceso a proyectos.
• Consenso entre anotadores: la misma tarea se asigna a varias personas y la etiqueta final sale del acuerdo. Apartarse del grupo sin justificación sólida es una señal en contra; si el grupo entero se divide, la tarea escala a un revisor senior.

La lógica del consenso cabe en unas líneas:

// lib/consensus.ts

// Etiquetas de varios anotadores para la misma tarea.
// Devuelve la etiqueta mayoritaria, el nivel de acuerdo y si necesita revisión.
export function consensus(labels: string[], threshold = 0.7) {
  const counts = new Map<string, number>();
  for (const label of labels) {
    counts.set(label, (counts.get(label) ?? 0) + 1);
  }

  let winner = "";
  let max = 0;
  for (const [label, count] of counts) {
    if (count > max) {
      winner = label;
      max = count;
    }
  }

  const agreement = max / labels.length;
  return {
    label: winner,
    agreement,
    needsReview: agreement < threshold, // poco acuerdo: la decide un revisor senior
  };
}

# lib/consensus.py
from collections import Counter

# Etiquetas de varios anotadores para la misma tarea.
# Devuelve la etiqueta mayoritaria, el nivel de acuerdo y si necesita revisión.
def consensus(labels: list[str], threshold: float = 0.7) -> dict:
    counts = Counter(labels)
    winner, max_count = counts.most_common(1)[0]

    agreement = max_count / len(labels)
    return {
        "label": winner,
        "agreement": agreement,
        "needs_review": agreement < threshold,  # poco acuerdo: la decide un revisor senior
    }

<?php
// lib/consensus.php

// Etiquetas de varios anotadores para la misma tarea.
// Devuelve la etiqueta mayoritaria, el nivel de acuerdo y si necesita revisión.
function consensus(array $labels, float $threshold = 0.7): array {
    $counts = array_count_values($labels);
    arsort($counts);

    $winner = array_key_first($counts);
    $max = $counts[$winner];

    $agreement = $max / count($labels);
    return [
        "label" => $winner,
        "agreement" => $agreement,
        "needsReview" => $agreement < $threshold, // poco acuerdo: la decide un revisor senior
    ];
}

De aquí sale una consecuencia práctica: leer la guía del proyecto completa antes de la primera tarea no es opcional, porque tu desempeño se mide contra el criterio compartido del proyecto, no contra tu intuición. Y cuando un proyecto entero muestra desacuerdo alto entre anotadores, el problema suele estar en las instrucciones, no en las personas.

Plataformas, requisitos y pago

El acceso a estos trabajos pasa casi siempre por plataformas especializadas: DataAnnotation, Outlier (de Scale AI), Appen, Alignerr, Surge AI y Prolific están entre las más conocidas. El flujo general se repite:

1. Registro y examen de calificación: pruebas de comprensión lectora, escritura y seguimiento de instrucciones antes de ver trabajo pagado. Los proyectos de dominio (código, matemáticas, derecho, medicina) tienen exámenes adicionales.
2. Asignación por proyecto: el trabajo llega en proyectos con instrucciones propias, volumen limitado y fecha de cierre; no es un flujo constante.
3. Periodo de prueba: las primeras tareas se revisan con más atención o son directamente tareas de control, y la precisión en ese tramo define si sigues.
4. Pago por hora o por tarea, según plataforma y proyecto.

Sobre cuánto se gana: no cito tarifas porque cambian por país, idioma y proyecto, y cualquier cifra quedaría desactualizada pronto. La estructura sí es estable: los proyectos generalistas pagan menos que los especializados en programación, matemáticas o derecho, donde las plataformas buscan perfiles escasos y el filtro de entrada deja fuera a la mayoría. Un desarrollador que revisa código generado por modelos compite en un grupo mucho más pequeño que quien hace clasificación general, y el pago refleja esa escasez.

Cuatro realidades del formato antes de entrar: casi todo es por contrato, sin garantía de horas; hay semanas con proyectos abundantes y semanas sin nada, así que al inicio es más realista tratarlo como ingreso complementario; casi todas las plataformas exigen acuerdos de confidencialidad que impiden contar en qué proyecto trabajas; y los proyectos de moderación implican leer contenido tóxico o perturbador —las plataformas serias lo advierten y lo hacen opcional, pero existe—.

Por qué la calidad del dato importa más que el volumen

Este es el punto que me parece más importante del artículo: el dato anotado no es un insumo neutro, es la definición operativa de “correcto” que el modelo va a aprender.

Un ejemplo de cómo se propaga el error: si los revisores de un proyecto premian sistemáticamente respuestas largas y seguras de sí mismas sin verificar los hechos, el modelo aprende que largo y seguro es mejor, y produce respuestas largas y seguras, correctas o no. Ese mecanismo tiene nombre en la literatura (reward hacking, y su variante conversacional, la adulación o sycophancy) y no es un fallo del modelo: es el modelo optimizando exactamente la señal que los humanos le dieron. La rúbrica y la disciplina del revisor son la defensa.

Lo mismo aplica en pequeño. Cuando un modelo dentro de un producto clasifica mal, la reacción instintiva es cambiar de modelo o reescribir el prompt; con frecuencia el problema real está en los ejemplos con los que se definió la tarea. En mis proyectos, cada hora invertida en revisar salidas reales con una rúbrica explícita valió más que la misma hora ajustando prompts sin datos. Es la misma economía que mueve a la industria: una etiqueta bien pensada mejora todas las predicciones futuras; una etiqueta apurada enseña el error a escala.

Preguntas frecuentes

¿Necesito saber programar para trabajar en anotación de datos?

No para las tareas generalistas: clasificación, comparación de respuestas y transcripción piden comprensión lectora, escritura clara y disciplina con las instrucciones. Programar abre el segmento mejor pagado —revisar código generado por modelos, evaluar razonamiento técnico—, y lo mismo vale para matemáticas, derecho, medicina o finanzas.

¿Qué es RLHF, en corto?

Aprendizaje por refuerzo con retroalimentación humana: personas comparan respuestas del modelo y eligen la mejor, y el modelo se ajusta para producir el tipo de respuesta que los humanos prefieren. Es la técnica que convirtió a los modelos base en asistentes útiles, y la razón por la que existe el trabajo de revisar respuestas de IA.

¿Cuánto pagan estos trabajos?

Varía tanto por país, idioma, plataforma y especialización que cualquier cifra concreta engaña más de lo que informa. La estructura sí es estable: las tareas generalistas están en la parte baja del rango y las de dominio experto en la alta. Desconfía de anuncios que prometen ingresos altos garantizados sin filtro de entrada: el filtro exigente es precisamente la señal de que el proyecto paga bien.

¿Cómo distingo una plataforma seria de una estafa?

Tres señales. Una plataforma seria nunca te pide dinero por entrar: si hay que pagar por “acceso”, “certificación” o “materiales”, es una estafa. Tiene proceso de calificación con exámenes, porque el cliente paga por calidad. Y paga por métodos verificables con historial público de pagos. Ante la duda, busca experiencias recientes de otros anotadores; la comunidad es grande y las estafas se reportan rápido.

¿Este trabajo va a desaparecer por los datos sintéticos?

La parte mecánica se está automatizando: los modelos ya preetiquetan datos y generan parte de su propio material de entrenamiento. Pero la señal de qué es correcto, seguro y útil sigue necesitando origen humano, sobre todo en dominios expertos, casos ambiguos y evaluación de modelos nuevos. La tendencia no es la desaparición del trabajo sino su desplazamiento: menos volumen generalista, más revisión experta y mejor pagada.

Conclusión

Los trabajos de anotación de datos y revisión de respuestas de IA son la capa humana del entrenamiento: personas que fabrican, ejemplo por ejemplo, la definición de “respuesta correcta” que un modelo va a aprender. La anotación clásica sigue existiendo, pero el crecimiento está en las tareas de juicio, donde el producto de trabajo no es el clic sino el criterio.

Si te interesa entrar, este es el orden que yo seguiría: entiende primero el pipeline de entrenamiento, para saber qué señal produce tu tarea; practica el formato central del oficio —elegir entre dos respuestas y justificar la elección con hechos verificados—; elige el dominio donde ya tienes ventaja real, porque la especialización es lo que se paga; y aplica a plataformas conocidas tratando los exámenes de calificación y las tareas de control como lo que son: el mecanismo con el que el sistema decide cuánto vale tu juicio.