DataToForm no nació de un solo momento. Surgió de dos situaciones distintas, en contextos muy diferentes, que planteaban exactamente el mismo problema — y para las cuales no existía ninguna solución directa.
Caso 1 — Las finanzas y sus formularios regulatorios
En los equipos financieros, los datos viven en Excel. Archivos densos y complejos: múltiples hojas, celdas combinadas, columnas calculadas, estructuras no normalizadas que han evolucionado con los años. Estos datos —carteras, posiciones, características de contratos, informes de riesgos— deben introducirse regularmente en portales regulatorios, back-offices propietarios, herramientas de reporting impuestas por proveedores o autoridades supervisoras.
Ninguno de estos sistemas expone una API utilizable. Algunos tienen APIs internas, cerradas, sin documentación. Otros son aplicaciones web de hace diez años que nunca fueron diseñadas para integrarse automáticamente.
El resultado: un analista que necesita procesar cincuenta expedientes en un portal regulatorio pasa media jornada copiando lo que ya está en su hoja de cálculo. Copiar el código ISIN. Cambiar de ventana. Pegar. Copiar el valor nominal. Cambiar. Pegar. Repetir por cada campo, cada fila, cada declaración.
El problema se vuelve crítico cuando los datos cambian. Una actualización de referencia, una corrección de valoración — y hay que empezar de nuevo. Sin importación, sin sincronización, solo alguien reescribiendo lo que otra persona ya introdujo en otro lugar.
Caso 2 — La agencia y la reintroducción multilingüe
En las startups con presencia internacional y en las agencias de comunicación que gestionan sitios web de clientes en varios idiomas, aparece una variante diferente del mismo problema.
El equipo de contenido prepara los textos en Excel o Google Sheets: una columna por campo, un conjunto de columnas por idioma. titulo_es, descripcion_es, titulo_en, descripcion_en, titre_fr, description_fr. Una fila por artículo, por ficha de producto, por página de destino.
Luego viene la introducción en el back-office — WordPress, Drupal, Strapi, un CMS propio, lo que sea. Abrir la interfaz de administración, crear el contenido en español, rellenar campo por campo. Luego cambiar a la versión inglesa, volver a crear el mismo contenido, rellenar de nuevo. Luego francés. Por cada artículo. Por cada idioma.
Lo peor no es la introducción inicial — es la reintroducción. El cliente pide reformular un párrafo, ajustar el tono, corregir una traducción. Hay que encontrar cada entrada en cada idioma, abrir cada formulario, editar cada campo. Una actualización de contenido puede costar tanto tiempo como la introducción original. Para una agencia que factura por horas, es trabajo no facturable. Para una startup sin desarrollador disponible, es una carga que se acumula y se pospone.
Lo que comparten ambos casos
Finanzas regulatorias y back-offices CMS multilingüe: nada en común en la superficie. Y sin embargo, la estructura del problema es idéntica.
Los datos ya existen. Están en un archivo estructurado, limpio y validado. Alguien ya los introdujo, verificó y aprobó.
El destino es conocido. Es un formulario web en pantalla, con campos específicos que esperan valores específicos.
El trabajo intermedio es puramente mecánico. Mirar el valor en Excel, encontrar el campo correcto en el formulario, copiarlo, repetir. Sin valor añadido — solo fricción y una fuente de errores.
En ambos casos, la pregunta es la misma: ¿por qué alguien tiene que hacer esto a mano?
Por qué las herramientas existentes no ayudaban
Zapier y Make conectan aplicaciones a través de APIs y webhooks. Son excelentes cuando ambos lados tienen un conector disponible. ¿Un portal regulatorio propietario o un back-office sin API? Fuera de alcance.
Las herramientas RPA (UiPath, Power Automate Desktop) pueden interactuar con interfaces web, pero requieren un desarrollador para configurar cada formulario y mantenimiento continuo cuando las interfaces cambian. Eso no es una herramienta — es un proyecto.
Los agentes IA autónomos (Browser Use, Skyvern, Operator) son una categoría más reciente. Abren un navegador, "entienden" la página y actúan de forma independiente. Prometedor — excepto que envían automáticamente. Para una declaración regulatoria o una publicación de contenido en producción, dejar que una IA decida sin revisión humana crea riesgos reales: datos malinterpretados, contenido publicado sin validación, sin posibilidad de corrección tras el envío.
La pregunta que formalicé
¿Se puede automatizar el copiar-pegar sin eliminar al humano del proceso?
Cinco condiciones implícitas:
- Fuente: un archivo Excel o CSV existente, sin reformatear
- Destino: cualquier formulario web, sin API, sin conector
- Inteligencia: la IA sugiere la correspondencia columnas → campos
- Control: el humano valida el mapeo antes del relleno
- Parada deliberada: el formulario se prerellena, y ahí paramos — el humano envía
La quinta condición es la más estructural. Separa DataToForm de todos los agentes autónomos — no por defecto, sino por diseño.
Primer boceto de la solución
Tres componentes sobre el papel:
Un parser de Excel inteligente. Los archivos reales tienen celdas combinadas, títulos en medio de los datos, múltiples hojas, columnas calculadas. SheetJS puede leerlos, pero comprender su estructura requiere ayuda — una primera llamada LLM para identificar las verdaderas columnas de datos.
Un inspector de formularios en un navegador real. Playwright abre un Chromium real, carga la página con su JavaScript y sus componentes dinámicos. El inspector lee lo que el navegador renderiza realmente — campos visibles, sus etiquetas, sus tipos.
Un LLM como puente semántico. Nunca ve los valores del archivo — solo los nombres de columnas y las etiquetas de los campos. Entiende que titulo_en corresponde al campo "Título (inglés)" en el back-office, que ISIN va en "Código de valor". Semántica pura, sin acceso a los datos.
El siguiente paso era escribir el código. De eso trata el Episodio 2.