← SCRAM AI Lab

Herramientas IA

RPA REPSE/IMSS con Playwright + undetected-chromedriver

Guía técnica para implementar RPA en portales del SAT, IMSS y REPSE usando undetected-chromedriver y Playwright con arquitectura para entornos de producción.

May 21, 2026

493 lecturas

RPA REPSE/IMSS con Playwright + undetected-chromedriver

El RPA de portales gubernamentales mexicanos no es ingeniería — es contraespionaje

Los portales del SAT, IMSS, REPSE e Infonavit fueron diseñados en 2008 y desde entonces les han pegado parches anti-bot. Detectan Selenium clásico, headless Chrome y user agents genéricos en menos de 3 segundos. Los webdriver.navigator tags están marcados, las fingerprints de canvas se comparan contra blacklists, y el timing de los clicks es analizado. Si vas a hacer RPA serio sobre estos sitios, el stack que aguanta producción en 2026 es undetected-chromedriver (Python) + Playwright para flow control + 2captcha para los retos visuales.

¿Es legal automatizar trámites en REPSE e IMSS con herramientas de RPA?

La legislación mexicana no prohíbe el uso de RPA para consultar información pública o gestionar trámites propios en REPSE e IMSS, siempre que se utilicen credenciales autorizadas por el contribuyente y no se vulneren sistemas informáticos según el Código Penal Federal; sin embargo, los términos de uso de los portales pueden restringir accesos masivos automatizados.

Desde la reforma laboral de subcontratación en 2021 regulada por la Secretaría del Trabajo y Previsión Social (STPS), las empresas en México están obligadas a retener y validar bimestralmente el cumplimiento de cada proveedor de servicios especializados. Para un corporativo que gestiona más de doscientos contratistas, verificar manualmente el padrón público del REPSE, la Opinión de Cumplimiento 32-D ante el SAT y las cédulas de liquidación del IMSS implica cientos de horas de personal administrativo. La automatización se convierte en una necesidad operativa, pero debe implementarse respetando la privacidad de datos bajo la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP).

Por qué no Selenium plain ni Playwright headless

  • Selenium clásico: tira en el login del SAT en el 70% de los intentos
  • Playwright headless: tira en captchas reCAPTCHA v3 con score <0.3
  • Chrome real con extensión: funciona pero no escala — necesitas display server

La combinación undetected-chromedriver con Playwright como controlador resuelve: UC parchea las firmas del navegador, Playwright orquesta el flow con su API más robusta que Selenium.

Comparativa técnica de herramientas para portales gubernamentales

A continuación se evalúan las principales alternativas de automatización frente a las defensas perimetrales implementadas por dependencias públicas en México:

Criterio de Evaluación Selenium Estándar Playwright Headless Puro Undetected + Playwright Servicios SaaS Sin Servidor
Evasión de WAF (F5 / Akamai) Baja (bloqueo por navigator.webdriver) Media (detectable por fingerprint de WebGL) Alta (binarios parcheados y canvas real) Media (rotación de IPs, pero huellas rígidas)
Consumo de memoria por worker ~150 MB por hilo ~220 MB por contexto ~450 MB (requiere Xvfb/display virtual) Nulo en infraestructura local
Costo mensual estimado (infraestructura) Bajo (~$20 USD en VPS básico según AWS) Bajo (~$25 USD en VPS básico según AWS) Medio (~$80 USD por instancias con GPU/Xvfb) Alto (tarifas por petición consumida)
Resiliencia a reCAPTCHA v3 / retos visuales Falla frecuente (score inferior a 0.3) Falla moderada sin perfiles humanos Alta integrando servicios como 2Captcha Variable dependiendo del vendor
Mantenimiento ante cambios en portales Crítico (re-escritura constante de selectores) Moderado (auto-waiting de selectores) Moderado (selectores auto-esperados y robustos) Dependiente de soporte externo

Stack típico

# requirements.txt
playwright==1.49.0
undetected-playwright-patch==1.40.0
2captcha-python==1.5.1
fastapi==0.115.0
rq==2.0.0
redis==5.2.0
from undetected_playwright import stealth_async
from playwright.async_api import async_playwright
from twocaptcha import TwoCaptcha

async def login_sat(rfc: str, password: str, captcha_solver: TwoCaptcha):
    async with async_playwright() as p:
        browser = await p.chromium.launch(
            headless=False,  # headed gana
            args=['--disable-blink-features=AutomationControlled'],
        )
        context = await browser.new_context(
            locale='es-MX',
            timezone_id='America/Mexico_City',
            user_agent=REAL_CHROME_UA,
        )
        await stealth_async(context)
        page = await context.new_page()

        await page.goto('https://www.sat.gob.mx/...')
        await page.fill('#rfc', rfc)
        await page.fill('#password', password)

        # captcha image
        captcha_src = await page.locator('img.captcha').get_attribute('src')
        result = captcha_solver.normal(captcha_src)
        await page.fill('#captcha', result['code'])

        await page.click('#submit')
        await page.wait_for_url('**/dashboard', timeout=30000)

Retry con backoff para el SAT a fin de mes

Los portales gubernamentales tiran 503 durante la última semana del mes (declaraciones, reportes IMSS). Tu RPA tiene que respetarlo: si reintentas agresivo, te marcan IP y te bannean por 24h. Patrón: 3 reintentos con backoff exponencial (30s, 90s, 300s) y si tras eso sigue 503, encolar para el siguiente día.

@retry(
    stop=stop_after_attempt(3),
    wait=wait_exponential(multiplier=30, min=30, max=300),
    retry=retry_if_exception_type((TimeoutError, HTTPError)),
)
async def fetch_repse_status(rfc: str):
    return await rpa_session.fetch(rfc)

Arquitectura en producción

Un worker FastAPI recibe la solicitud (autenticada por JWT del CRM), encola un job en Redis Queue, un pool de 4 workers Python con undetected-chromedriver corre los flows en contenedores Docker. Cada worker tiene su propio display virtual (Xvfb) porque headed > headless. Pool size limitado por costo de 2captcha (~$0.003 USD por captcha resuelto).

Gestión de proxies residenciales en México

Si ejecutas cientos de consultas desde el rango de direcciones IP de un centro de datos común (como AWS us-east-1 o DigitalOcean), los firewalls perimetrales de dependencias gubernamentales en México aplicarán límites de tasa (rate limiting) de inmediato. En producción se requiere enrutar las sesiones mediante proxies residenciales rotativos o proxies móviles locales con salida geográfica en la Ciudad de México, Guadalajara o Monterrey. Esto reduce las banderas de anomalía en un 80% y asegura que los tiempos de respuesta del servidor correspondan al tráfico nacional.

Compliance no negociable

Nunca almacenar credenciales del cliente. Cada sesión de RPA pide login interactivo desde la UI del cliente, las credenciales viven en memoria del worker durante la sesión y se purgan al terminar. Si el cliente quiere "recordame", esa decisión la toma el CFO/CISO del cliente firmando algo, no tu equipo de devs. Hemos visto demandas civiles por esto.

  • No localStorage, no Redis, no Postgres con credenciales
  • Logs estructurados con RFC hasheado, nunca el password
  • Auditoría: cada RPA run logueado con timestamp, RFC hash, acción, resultado
  • Time-box: sesiones expiran en 15 min de inactividad

Manejo de archivos criptográficos: CIEC y e.firma

Muchos trámites tributarios del SAT y del IMSS (como IDSE) no se resuelven con usuario y contraseña simples; exigen certificados digitales (.cer) y llaves privadas (.key). Para procesar estos flujos en una arquitectura RPA segura, el archivo de llave privada debe descifrarse eficientemente en memoria volátil sin tocar el disco del contenedor contenedor de Docker. Utiliza librerías criptográficas de Python para validar la frase de paso antes de enviarla al input file del navegador y limpia las variables de entorno inmediatamente después de la emisión de la firma electrónica.

Qué puede salir mal y cómo mitigarlo

La tasa de falla en procesos automatizados de plataformas estatales supera con frecuencia el 25% por factores ajenos al código del cliente. Documentar y prever los escenarios de caída salva contratos de soporte:

  • Desincronización de Xvfb y fugas de memoria: Los navegadores no controlados que corren en pantallas virtuales pueden acumular procesos huérfanos de Chrome tras interrupciones de red. Implementa un script de limpieza periódica con supervisores de procesos para destruir hilos zombies que superen los 10 minutos de ejecución.
  • Modificaciones silenciosas en el árbol DOM: Es habitual que el personal de TI gubernamental modifique identificadores de elementos sin previo aviso durante los fines de semana. Evita selectores frágiles como div > div:nth-child(3) > input y prioriza selectores basados en atributos de accesibilidad, textos visibles normalizados o posiciones relativas de etiquetas de formulario.
  • Costos imprevistos de resolución de captchas: Un bucle de reintentos mal calibrado frente a un formulario colapsado puede agotar el saldo de servicios de resolución externa. Según la documentación de tarifas oficiales de 2Captcha, cada mil captchas tradicionales cuestan $3.00 USD; sin embargo, resolver bucles infinitos de reintentos puede encarecer la factura innecesariamente. Define invariablemente un circuito de corte (circuit breaker) que pause el worker tras tres fallos consecutivos de resolución.

El gato y el ratón continúa

El SAT actualizó sus detecciones en marzo 2025; UC tardó 3 semanas en parchear. Si tu negocio depende de RPA sobre portales gubernamentales, tu plan B siempre debe ser "operador humano con script semi-asistido". Automatizamos lo que no es crítico, dejamos al humano lo que cuesta una multa.

La pregunta del decenio: ¿cuánto falta para que el SAT exponga una API oficial decente y este artículo sea histórico? Spoiler: no en este sexenio.

rpa
sat
imss
playwright
← Volver a SCRAM AI Lab