RPA gubernamental como SaaS

Tenía un motor que consulta portales públicos del Estado colombiano y devuelve datos en segundos. La pregunta no era “¿funciona?” sino “¿esto es un negocio vendible sin terminar sancionado?”. Este caso es la capa de producto y de riesgo encima del motor.

Stack: Python (stdlib) · SQLite · diseño SaaS multi-tenant · Estado: MVP + análisis GTM · Rol: producto + desarrollo (solo)

Ver también: transito-co — el motor técnico debajo de esto (captcha, OCR, scraping, evasión de WAF). Aquí no repito esa ingeniería; este caso es qué hice con ese motor.

El problema / la oportunidad

El dato público colombiano (registro de empresas, afiliación a seguridad social, multas, listas de control) es gratis pero está atrapado detrás de portales lentos, captchas y consultas de a una. Verificar 1 registro a mano: molesto. Verificar 5.000: días de trabajo y errores de digitación.

El insight de negocio es que no vendes el dato —es público y gratis—; vendes automatización + agregación + frescura + monitoreo. El margen de cómputo es brutal (~85-97%) porque el costo marginal de una consulta son centavos. Pero ese mismo “agregar y revender dato público sobre terceros” es exactamente lo que la SIC ya sancionó. La oportunidad real es del que sepa navegar el filo legal, no del que sepa hacer scraping.

Mapeé tres líneas de producto sobre el mismo motor, ordenadas por riesgo legal en vez de por demanda:

Línea	Demanda (WTP)	Riesgo Habeas Data	Listo para vender
Leads B2B (empresas, dato público)	Medio-alto	Bajo	Primero — arranca aquí
Tránsito / vehicular	Alto	Medio	2º (con contratos)
Salud / seguridad social (dato sensible)	El más alto	Alto	3º (sólo con abogado)

La secuencia es deliberadamente al revés de la intuición: empiezo por la línea de menor riesgo aunque no sea la de mayor WTP, porque un primer cliente que no me expone legalmente vale más que el contrato grande que me puede costar una sanción.

Qué construí

1. Generación de leads B2B sobre dato público. El primer producto vendible no toca datos personales. Extrae empresas por código de actividad económica (CIIU) + ciudad desde el registro público de empresas, con paginación, y arma un CSV segmentado. La pieza que lo vuelve recurrente es el feed de empresas nuevas: filtra por fecha de matrícula y entrega “las que se registraron esta semana en tal sector/ciudad”. Una empresa recién creada necesita todo a la vez (seguros, contador, software, datáfono) y hay ventana de exclusividad → eso es MRR para quien le vende.

Enriquecimiento de contacto con criterio. A cada empresa le agrego el contacto público del negocio (teléfono, dirección, web, reseñas) desde la API de mapas. Decisión deliberada: enriquezco el dato del local comercial —que el propio negocio publica— y nunca el dato personal del representante legal. Como el nombre legal del registro no siempre coincide con el comercial, devuelvo un score de confianza (similitud de nombres) para que el cliente filtre los dudosos en vez de venderle ruido.

2. Un MVP de SaaS funcional, no un mockup. Servidor HTTP en biblioteca estándar de Python (sin framework, sin pip install), Basic Auth, SQLite con WAL, y un worker en background. El flujo de producto completo corre en un solo proceso:

subir CSV → cola de jobs → motor consulta (throttled) → CSV de resultados + billing

El esquema es el del MVP real, no uno de juguete — cuatro tablas: orgs, batches, jobs, usage_events. El worker reclama jobs de forma atómica (pending → running), respeta un throttle entre consultas reales (rate-limiting legítimo, no martillar el portal ajeno), y un job que falla no tumba al worker.

3. Metering por consulta. Cada job cobrable inserta un usage_event con su precio. El panel calcula consultas facturadas, ingreso y margen en vivo. Esto fija la unit economics del pitch en números reales: precio simulado ~$0.15/consulta sobre un costo real de ~$0.007 → el reporte consolidado que el portal oficial cobra a precio de trámite, yo lo produzco por una fracción de centavo.

Lo modelé como demo local de costo cero que mapea 1:1 a la versión cloud, para poder vender el MVP sin pagar infraestructura hasta tener el primer cliente:

Demo (local, $0)	MVP cloud
SQLite (un archivo)	Postgres gestionado
worker = 1 thread	cola gestionada + contenedor
http.server	framework web + serverless
tabla usage_events + panel	billing metered (Stripe)
org única	auth multi-tenant

Decisiones interesantes

Multi-tenant desde la primera línea de schema. El MVP corre con una sola Demo Org, pero org_id ya cuelga de cada batch y cada evento de uso. La migración a multi-tenant real es cambiar el proveedor de identidad, no rediseñar el modelo de datos. Construí el atajo (org única) sin pintarme a una esquina.

Metering como usage_events append-only, no un contador. Un contador que incrementás es imposible de auditar y de reconciliar contra el cobro. Un log inmutable de eventos con precio y timestamp es la fuente de verdad tanto para facturar como para defender una factura. Es la misma forma que tiene el billing metered serio; lo dejé montado así desde el demo.

La estructura legal como parte del diseño del producto — lo que más me importa de este proyecto. Existe un precedente colombiano casi idéntico: la SIC sancionó a una empresa (~$190M COP + suspensión de 6 meses) por agregar y revender dato público sobre terceros. Las lecciones, traducidas a decisiones de arquitectura:

• “Es dato público” no blinda nada. Fue su defensa y falló: agregar y perfilar cambia la finalidad, y el dato deja de ser de libre circulación. El delito no es consultar, es acumular.
• Por eso el producto es deliberadamente una figura de “Encargado que no almacena”: una tubería ciega que consulta y devuelve, sin construir una base de datos consultable propia. La tentación de cachear todo para revender es justo el pecado que costó la sanción; no almacenar es una decisión de diseño, no una omisión.
• Gate de consentimiento aplicado en dos capas (Ley 1581 / Habeas Data): una fila sin referencia de autorización del titular se rechaza antes de gastar la consulta, y otra vez dentro del worker. Un rechazo no consulta ni se cobra, y queda anotado. El consentimiento no es una casilla cosmética en la UI: está cableado en la cola.
• Contrato de transmisión de datos (la figura legal local equivalente) donde el cliente declara y garantiza tener la autorización de cada titular, más oferta de despliegue self-hosted para clientes grandes (traslada el riesgo a su propia infraestructura).
• Para las líneas de dato sensible (salud / seguridad social), el veredicto explícito es no lanzar sin concepto de abogado de protección de datos. Saber cuándo no enviar un producto es parte del trabajo.

La línea innegociable que atraviesa las tres líneas de negocio: consultar y entregar, nunca construir tu propia base agregada. Esa frase es a la vez la postura legal y la restricción de arquitectura.

Qué demuestra

• Pensamiento de founder, no de implementador: priorizar por riesgo legal en vez de por demanda; elegir como primer producto el de menor exposición; modelar unit economics reales con un metering que funciona.
• Ingeniería pragmática: un SaaS de extremo a extremo —auth, cola, persistencia, worker, metering, billing— en biblioteca estándar, con un schema que ya es multi-tenant y un mapa explícito demo→cloud para no reescribir al escalar.
• Criterio legal y ético tratado como requisito de ingeniería: leer un precedente regulatorio real y dejar que reescriba la arquitectura (no almacenar, gate de consentimiento en la cola, contrato de transmisión, self-hosted, freno duro en dato sensible). Entender el riesgo legal es parte de diseñar el producto.

Estado y siguiente paso

Honesto sobre dónde está: MVP funcional + análisis de go-to-market, no un negocio en operación a escala. Lo que existe y corre hoy: el motor verificado, la generación de leads B2B, el demo SaaS de extremo a extremo con metering, y el diseño legal y multi-tenant.

Lo que falta para que sea negocio: cliente ancla en la línea de leads (el camino de menor riesgo), migrar el demo a la versión cloud (el mapa 1:1 ya está hecho), y —antes de tocar cualquier vertical de dato sensible— el concepto del abogado de datos y, si se escala, la consulta previa al regulador. El orden de ejecución es el mismo que el de riesgo: leads → tránsito con contratos → salud sólo con blindaje legal.

Nota: esto es criterio de producto y análisis estratégico, no asesoría legal. Las líneas de mayor riesgo no se lanzan sin concepto profesional de protección de datos.