Un scraper que falla en silencio es peor que uno que se cae. El que se cae te avisa. El que falla en silencio te entrega un CSV con la mitad de las filas, el pipeline corre en verde, el dashboard se actualiza y alguien toma una decisión con datos incompletos sin enterarse nunca.
Esto empeoró con los agentes de IA, y por una razón estructural. Un agente no te marca su propia incertidumbre: la resuelve en silencio. Si la instrucción era ambigua, elige una interpretación con total seguridad y sigue. Si el selector no matchea, puede devolver una lista vacía en lugar de fallar. Si el campo no existe, puede poner
nullPor eso la validación de datos extraídos no es un paso final de prolijidad: es la parte del trabajo que decide si tenés un dataset o un archivo con forma de dataset. Acá van los siete chequeos que conviene exigir antes de dar un scraper por bueno, con el criterio de ingeniería que hay detrás de cada uno.
La regla que ordena todo: quien hace el trabajo no se pone la nota
Antes de la lista, el principio. En Agentic Engineering, Addy Osmani lo plantea como una restricción no negociable: el agente que hizo el trabajo nunca decide que está bien. Un subagente redacta y otro verifica.
Ken Kousen, en Claude Code: Up and Running, llega al mismo lugar desde otro ángulo con una frase que se puede aplicar a cualquier entrega de datos:
Los reportes son testimonio, no evidencia.
Cuando un agente te dice "el scraper funciona correctamente y extrajo los datos solicitados", eso no es un hecho: es una afirmación que todavía tenés que verificar. Y la forma de verificarla es contra el dato, no contra el resumen.
Hay un caso en el libro de Kousen que deja esto claro. Un badge de precio y las recomendaciones de un producto estuvieron roto seis semanas sin que nadie se diera cuenta, porque un error 400 quedaba oculto detrás del frontend. No había alerta, no había test que lo cubriera, y el sistema seguía corriendo. Los chequeos de abajo existen para que ese tipo de falla dure horas, no semanas.
1. Conteo de registros contra la media histórica
El chequeo más simple y el que más atrapa. No alcanza con "¿devolvió filas?". La pregunta es ¿devolvió la cantidad de filas que devuelve normalmente?
Qué configurar:
- Guardá el conteo de cada corrida.
- Compará la corrida de hoy contra la media de los últimos 7 días.
- Definí un umbral explícito de desvío que dispare alerta (por ejemplo, ±20%) y que bloquee la entrega si se pasa.
Un scraper que pasó de 12.000 a 11.400 registros probablemente está bien. Uno que pasó de 12.000 a 400 cambió de sitio, no de catálogo. Y uno que pasó de 12.000 a 12.000 exactos durante cinco días seguidos quizás esté devolviendo un cache.
2. Porcentaje de nulos por campo obligatorio
Un conteo correcto puede esconder filas vacías. El segundo chequeo mira adentro.
Separá los campos en obligatorios y opcionales, y poné un techo de nulos para cada obligatorio. Si el SKU, el precio, la moneda o la URL son obligatorios, un 1% de nulos ya es una señal; un 15% es un scraper roto que todavía no se cayó.
Lo importante es que el techo sea un número escrito, no un criterio. "Pocos nulos" no se puede chequear. "Menos del 1% de nulos en SKU, precio, moneda y URL" sí.
3. Validación de esquema estricta
El esquema no es documentación: es un portón. Cada registro se valida contra una definición de tipos antes de entrar al dataset, con herramientas como Pydantic en Python o equivalentes en tu stack.
Esto cubre tres fallas distintas:
- Tipos: un precio que llegó como texto
en lugar de número."1.299,00" - Formatos: una fecha que llegó en
cuando el contrato dice ISO.DD/MM/AAAA - Campos inesperados: un campo nuevo que apareció, o uno que desapareció.
Y hay una razón de seguridad además de calidad: si usás un modelo de lenguaje para extraer campos, un esquema estricto en la salida impide que una instrucción escondida en la página termine convertida en un campo con basura. Lo desarrollamos en la nota sobre prompt injection.
4. Rangos y reglas de negocio
Los tipos correctos no garantizan valores sensatos. Un precio de
0-509.999.999Reglas típicas que conviene escribir:
- Precios dentro de un rango razonable para la categoría.
- Fechas que no estén en el futuro (salvo que el caso lo justifique, como vuelos o eventos).
- Stock como entero no negativo.
- Monedas dentro de una lista cerrada.
- Coherencia entre campos: si hay precio con descuento, que sea menor que el precio de lista.
Este es el chequeo que detecta el error más caro en pricing: no el dato que falta, sino el dato que está y está mal.
5. Deduplicación con clave explícita
Decidí de antemano qué hace único a un registro y chequealo. Suele ser una combinación: sitio + SKU + fecha, o URL + timestamp.
Dos fallas que atrapa:
- Duplicados por paginación: el scraper recorrió la página 3 dos veces porque el sitio reordenó el listado mientras extraía.
- Variantes colapsadas: dos talles del mismo producto que se guardaron como un solo registro, o al revés.
Esta última es una decisión de producto, no técnica, y es exactamente el tipo de ambigüedad que un agente resuelve solo si no se la definís. ¿Cada variante es una fila o una sola fila con un campo de variantes? Si no está escrito, cada corrida puede contestarlo distinto.
6. Tests de parsing contra fixtures guardados
Acá está el chequeo que más tiempo ahorra a largo plazo, y viene directo del libro de Kousen. La prueba de fuego que propone es una pregunta: ¿podés verificar esto sin abrir un navegador?
Si la respuesta es no, la lógica está atrapada en la interfaz. La solución es separar el scraper en tres piezas:
- Fetch: trae el HTML.
- Parsing: convierte HTML en registros.
- Normalización: limpia y tipa.
Con esa separación, guardás una muestra de HTML real como archivo (un fixture) y testeás el parser contra ese archivo, sin red, en milisegundos. El ejemplo del libro es una app que pasó a 15 tests corriendo en 129 milisegundos.
El beneficio concreto para un equipo de datos: cuando un sitio cambia, agregás el HTML nuevo como fixture y tenés un test que falla en la línea exacta. Sin pegarle al sitio, sin esperar la corrida nocturna, sin consumir proxies.
La contracara, que el mismo libro advierte: no mockees lo que no es tuyo. Si el sitio cambia, tus fixtures siguen pasando y no te enterás. Por eso los fixtures necesitan un acompañante: un chequeo periódico contra el sitio real que compare la estructura actual contra la guardada.
7. Muestra revisada por una persona
El séptimo chequeo no es automático a propósito. Una muestra de 20 a 50 registros, puesta al lado de la página de la que salieron, mirada por alguien.
Esto detecta la clase de error que ningún test cubre porque nadie pensó en medirlo: el campo "precio" que en realidad está trayendo el precio de financiación en 12 cuotas, la descripción que viene con el aviso de cookies pegado, el nombre del producto que incluye el nombre del vendedor.
Kousen tiene una pregunta de cierre que funciona muy bien acá: ¿qué nos olvidamos? Los tests verdes no detectan lo que no se pidió. En su ejemplo, con cinco navegadores en verde, la revisión global encontró que faltaba soportar la flecha izquierda del teclado. Nadie lo había pedido y nadie lo había testeado.
Cómo blindar la checklist: que el agente no pueda aflojar el verificador
Hay un detalle de implementación sin el cual los siete chequeos no sirven de nada.
Un test rojo se puede poner verde de dos maneras: arreglando el código o debilitando el test. Un agente que tiene como objetivo "que los tests pasen" puede bajar un umbral, comentar un assert o agregar un reintento, y declarar victoria. El libro de Kousen lo llama "no mover los postes" y propone una defensa concreta: un hook que bloquee las ediciones a los tests, a la configuración de umbrales y a los workflows de integración continua, incluidos los intentos por línea de comandos.
La regla queda así: el agente puede editar el extractor; no puede editar lo que lo juzga.
Y al revisar, mirá primero los tests que cambiaron. Lo peor que puede pasar en un pull request de mantenimiento no es un parser mal escrito: es un chequeo debilitado que hace pasar todo.
La checklist, en una tabla
| # | Chequeo | Falla que detecta | Umbral que hay que escribir |
|---|---|---|---|
| 1 | Conteo vs. media de 7 días | Extracción parcial, paginación cortada | Desvío máximo aceptable (ej. ±20%) |
| 2 | Nulos por campo obligatorio | Selector roto en un campo | Techo de nulos por campo (ej. <1%) |
| 3 | Validación de esquema | Tipos y formatos cambiados | Esquema versionado |
| 4 | Rangos y reglas de negocio | Valores presentes pero absurdos | Rango por campo y categoría |
| 5 | Deduplicación | Duplicados de paginación, variantes | Clave única explícita |
| 6 | Tests contra fixtures | Regresión de parsing | Tests que condicionan la entrega |
| 7 | Muestra revisada a mano | El error que nadie pensó en medir | Tamaño de muestra y periodicidad |
Los siete chequeos juntos son lo que Osmani llama el paquete de evidencia: diff, salida de tests, muestra de registros, conteos antes y después, y los campos que el agente no pudo resolver. Nada de "el agente dice que anda". Eso, en el vocabulario del libro, es teatro de verificación: que exista un chequeo no te hace seguro.
Dónde encaja esto en un servicio de datos
Si tu equipo está armando este sistema desde cero, el orden que recomienda Osmani es el inverso al intuitivo: primero los tests y los chequeos, después los dueños, después la especificación escrita, y recién ahí la autonomía del agente.
En Data Factory estos chequeos vienen adentro de la entrega: la validación no es algo que el cliente tiene que montar después de recibir el archivo. Si lo que necesitás es sumar gente senior que arme este sistema dentro de tu propio flujo de trabajo, con el código quedando de tu lado, eso es Data Squad.
Preguntas frecuentes
**¿Cuál de los siete chequeos implemento primero si tengo poco tiempo?**El conteo contra la media histórica (chequeo 1) y el porcentaje de nulos por campo obligatorio (chequeo 2). Son los dos más baratos de implementar y los que atrapan la mayor proporción de fallas silenciosas. Con esos dos ya pasás de "no sé si mi dataset está bien" a "me enteraría si se rompiera".
**¿Por qué no alcanza con que el scraper no tire errores?**Porque la ausencia de error no es señal de éxito. Un
try/except**¿Qué es un fixture y por qué conviene guardarlos?**Es una muestra de HTML real guardada como archivo. Sirve para testear el parser sin conexión, en milisegundos, y para tener un registro de cómo era el sitio en cada momento. Cuando el sitio cambia, el fixture nuevo más un test te señala exactamente qué se rompió.
**¿Cada cuánto conviene revisar una muestra a mano?**Depende de la criticidad de la entrega. Para un flujo diario de precios, una muestra semanal más una obligatoria cada vez que el sitio cambia de estructura. Para datos que alimentan decisiones financieras, en cada corrida con cambios. La muestra a mano es el único chequeo que detecta errores que nadie anticipó.
**¿Esta validación la puede hacer un agente de IA?**Sí, siempre que no sea el mismo agente que escribió el extractor y que los umbrales sean números escritos, no criterios. Mejor todavía: los chequeos 1 a 5 conviene que sean scripts deterministas, no un agente. Un script no se convence a sí mismo de que el resultado está bien.
Para seguir leyendo
- Scraping con IA: generar es barato, verificar sigue caro
- Cómo escribir la especificación de un proyecto de datos
- El loop nocturno que te ordena la mañana
- Scraping gestionado frente a in-house con agentes
- Pasos de la extracción de datos
- Métodos de recolección de datos
- Guía de métodos de extracción de datos con Python
