Lo que decides no construir define el sistema
Detección de señales en fuentes públicas oficiales. Un scraper por fuente, scoring auditable y la restricción legal como restricción de arquitectura.
- arquitectura
- scraping
- cumplimiento
- scoring
- trade-offs
Este es el subsistema de fuentes oficiales del diseño que conté en captación proactiva multiportal. No es un proyecto aparte: es la rama de ese embudo que lee boletines, edictos, registros de procedimientos, subastas y catastro. Lo separo porque sus decisiones son distintas a las del resto del sistema, y porque la decisión más importante de todo el diseño fue algo que dejé fuera.
Fuentes que no puedes controlar y un falso positivo que cuesta el sistema
Las fuentes públicas oficiales contienen señales de mucho valor comercial y están diseñadas para que las lea una persona, de una en una. No hay API. Publican en HTML inconsistente que cambia sin avisar, con periodicidades distintas y sin identificadores estables entre fuentes: el mismo activo aparece descrito de dos formas en dos registros y nada los une.
El problema de negocio es que ahí hay información que llega antes que al mercado. El problema de sistema tiene tres capas: construir sobre fuentes que no controlas, sobre formatos que cambian sin aviso, y con un coste de error asimétrico. Un falso negativo se pierde y nadie se entera. Un falso positivo llega a la bandeja de alguien, y bastan unos pocos para que esa persona deje de abrir las notificaciones. Ahí no has perdido una señal: has perdido el sistema entero, porque un detector que nadie mira no detecta.
Cinco decisiones sobre terreno que no controlo
Un scraper por fuente, con su propia cadencia. Cada fuente tiene su cliente HTTP, su parser y su entrada de planificación. Las fuentes diarias y las semanales no comparten planificador. Trade-off aceptado: código repetido entre scrapers y N piezas que mantener en vez de una, a cambio de que un cambio de formato en una fuente rompa exactamente una pieza y no las cinco.
Enriquecimiento por cruce como fase separada de la captura. La señal se captura primero cruda, sin normalizar, y se enriquece después cruzando con la fuente cartográfica oficial para obtener ubicación exacta y superficie. Trade-off aceptado: almacenamiento duplicado —el dato crudo y el enriquecido— y una fase más de latencia, a cambio de poder reprocesar todo el histórico cuando mejora el algoritmo de cruce, sin volver a golpear la fuente original. Volver a golpear la fuente original es lo que te bloquea la IP, y si te bloquean la IP no pierdes una ejecución: pierdes la fuente.
Scoring explícito y auditable, no clasificación opaca. Cada señal lleva una puntuación calculada con criterios explícitos, y los criterios que se aplicaron quedan almacenados junto a la señal. Trade-off aceptado: un modelo de puntuación por criterios acierta menos que uno entrenado sobre el histórico y hay que ajustarlo a mano, a cambio de que cuando un usuario pregunta "por qué me has mandado esto" haya una respuesta concreta. Un score de caja negra en un flujo comercial se ignora en dos semanas: la persona no puede discutirlo, así que deja de usarlo.
Enrutado por criticidad, no por zona. Las señales de este tipo no van al responsable de zona: van primero a dirección. Es la única categoría del sistema con esa regla, porque implican interlocución jurídica y no comercial. Trade-off aceptado: rompo la regla general de asignación del sistema y añado un caso especial que hay que explicar a todo el mundo, a cambio de que estas señales lleguen a quien puede actuar sobre ellas. Una regla de enrutado que contradice la regla general suele ser señal de que el diseño está atendiendo a la realidad y no a la simetría del diagrama.
Solo fuentes públicas y gratuitas, por diseño. La restricción legal se trató como restricción de arquitectura desde el primer diagrama: no como una revisión de cumplimiento al final, sino como una condición de contorno al mismo nivel que la latencia o el coste. Trade-off aceptado: el sistema tiene menos señales y menos capacidad de priorizarlas de la que técnicamente podría tener, a cambio de que no exista ningún camino en el código que haya que desmontar más adelante.
Lo que hay que mirar en el diagrama son dos cosas. Primera: la captura, el enriquecimiento y el scoring son tres fases distintas, no un paso. Segunda: la flecha de enrutado va siempre a dirección y nunca directamente al comercial de zona. Esa flecha es la excepción a la regla general del sistema.
Captura · cadencia propia por fuente
Qué descarté y por qué
Segmentar a las personas por capacidad económica. Este es el descarte que define el subsistema. Había un camino técnicamente viable para mejorar la priorización cruzando datos personales de varias fuentes y estimando capacidad económica. Habría mejorado el scoring de forma obvia. Lo descarté antes de dibujar el primer diagrama, y no por prudencia: por arquitectura.
El razonamiento es puramente de coste. Un sistema que se diseña primero y se pasa por cumplimiento después no se ajusta: se rediseña entero. Esa restricción, si llega al final, te obliga a tocar el modelo de datos, los flujos de enriquecimiento y la mitad de la lógica de scoring, porque los datos personales que ya has metido están atravesados en todo. Si llega al principio, es una línea que no cruzas y no hay nada que rehacer. Sale más barato en todos los escenarios, incluido el que nadie te audite nunca. Y por eso la menciono solo como el camino que se descartó, en abstracto: describir cómo se hace sería reintroducirlo.
El scraper genérico configurable. Descartado. Es la abstracción que todo el mundo intenta primero: un motor, un fichero de configuración por fuente, selectores declarados. Se rompe con la tercera fuente, y siempre por el mismo motivo: lo que varía entre fuentes no es la configuración, es la forma del problema. Una fuente pagina, otra publica un PDF, otra cambia la estructura del listado según el día. Cuando la configuración empieza a necesitar condicionales, has escrito un lenguaje de programación peor que el que ya tenías.
Capturar y enriquecer en el mismo paso. Descartado. Ahorra almacenamiento y una fase, y te obliga a volver a la fuente original cada vez que mejoras el cruce. Es el diseño que parece eficiente hasta la primera vez que te bloquean.
Scoring con clasificación opaca. Descartado aunque acertara más. En un flujo donde una persona decide si llamar o no, la precisión que no se puede defender no es precisión utilizable.
Enrutar estas señales por zona, como el resto. Descartado. Habría dejado el modelo de asignación perfectamente simétrico y habría puesto una interlocución jurídica en manos de un perfil comercial.
En qué punto está de verdad
Diseño entregado como subsistema del PoC de captación proactiva. No implementado de forma independiente, y el sistema del que forma parte tampoco se implementó.
Es un diseño. No hay ejecución, ni piloto, ni una sola señal capturada en producción. Lo digo así porque la alternativa —contarlo con verbos que sugieren que funciona— es la trampa que hace que después nadie se crea las cifras que sí son reales. Las que sí lo son están en otros productos: una utilidad de escritorio publicada y facturando en Microsoft Store, un gestor de instancias con miles de instalaciones, un SaaS fiscal propio en producción con clientes reales.
Lo transferible, y la lección que me toca a mí
La lección principal es la del título: lo que descartas define el sistema tanto como lo que construyes, y sale mucho más barato descartarlo antes de dibujar. Toda restricción que vas a tener que respetar al final es una restricción de arquitectura, y llevarla al principio no cuesta nada más que decidirla.
La segunda es sobre abstracciones. El scraper genérico configurable es una abstracción prematura que se justifica con un argumento correcto —no repetir código— aplicado al eje equivocado. Antes de abstraer hay que saber qué varía de verdad entre los casos.
La tercera: la explicabilidad no es un adorno de cumplimiento, es un requisito de adopción. Un score auditable con criterios almacenados se usa; uno opaco se abandona en dos semanas por la vía silenciosa de dejar de abrir la notificación.
Y la incómoda. Este subsistema es la mejor pieza de arquitectura de esta serie, y su estado sigue siendo "diseño entregado". Tomé bien la decisión difícil —dejar fuera el camino rápido cuando nadie me estaba mirando— y no tomé la fácil, que era implementar la primera fuente, entera, y ponerla a funcionar contra una bandeja de verdad. Decidir bien sobre el papel es la parte del oficio que me sale sola. Terminar es la que estoy aprendiendo.
Versión corta en LinkedIn: Lo que decides no construir — linkedin.com/in/carlosdelatorre-ai
Relacionado
- Captación proactiva multiportal: el filtro es el producto — el sistema del que este subsistema forma parte. Ahí están la tabla única, el clasificador y el escalado temporal.
- Diseñé una app de autoservicio que no guarda ni un dato del cliente — otra decisión de no construir: la base de datos propia.
- Fábrica de repaquetizado orquestada por agentes de IA — descartar el pipeline único, y por qué el triaje va antes de ejecutar.