La API no llega si te limitas a esperarla
Muchos sistemas de escritorio importantes (contabilidad, gestión, ERP más antiguos) no tienen API y, oficialmente, no la tendrán pronto en su versión de escritorio: las integraciones se quedan limitadas a la exportación/importación de ficheros en la que ya se basan otras herramientas del mercado.
Eso no significa que la automatización sea imposible — significa que hay que construirla de otra forma: leyendo directamente el formato nativo de los datos u operando de forma controlada la interfaz existente. La automatización de software sin API significa, en concreto, agentes de IA que operan exactamente la interfaz que tú mismo tendrías abierta — no una integración por API que, para muchos programas de contabilidad de escritorio, sencillamente no existe.
La vía preferida, cuando es posible
Cuando los datos son accesibles en disco o en red (bases de datos locales, ficheros nativos), la lectura directa es más rápida, más robusta y más segura que operar la interfaz: no depende de cómo se vea la pantalla y no puede «pulsar mal un botón».
La regla estricta que aplicamos: lectura directa sí, escritura directa nunca. Cualquier modificación pasa por el mecanismo oficial de importación del sistema origen, no por la manipulación directa de los ficheros de datos. A diferencia del RPA clásico, que sigue un script fijo de clics, un agente computer-use reconoce qué ha cambiado en la pantalla — una ventana movida, un menú renombrado — y se adapta, en lugar de fallar ante la primera diferencia. Para sistemas muy sensibles, donde ni siquiera la lectura directa de los datos es suficiente, explicamos por separado IA autoalojada, con los datos en tu propia infraestructura, como alternativa a operar sobre un programa existente.
Lectura directa de datos frente a automatización sobre la interfaz
Dos vías para un sistema sin API. Casi siempre las combinamos.
| Lectura directa de datos | Computer-use (sobre la interfaz) | |
|---|---|---|
| Cómo funciona | Lee el formato nativo: base de datos, DBF, PDF. | Ve la pantalla e interactúa como una persona: clic, escritura. |
| Velocidad | Rápido, sin abrir ninguna aplicación. | Más lento, depende de la velocidad de la interfaz. |
| Robustez | No depende del aspecto de la pantalla. | Sensible a los cambios de interfaz o de versión. |
| Cuándo se usa | Los datos son accesibles en disco o en red, solo para lectura. | La interfaz es la única vía: introducción de datos, validaciones en la aplicación. |
| Riesgo | Reducido, de solo lectura por diseño. | Mayor: entorno aislado más validación paso a paso. |
En la práctica, la mayoría de los proyectos combinan ambas cosas: lectura directa para el análisis, computer-use solo para los pasos que de verdad requieren interactuar con la interfaz.
Cuando la interfaz es la única vía
A veces no hay otra opción que el agente interactúe con la aplicación exactamente como lo haría una persona —clic, escritura, lectura de la pantalla— para pasos que no se pueden realizar leyendo/escribiendo ficheros (validaciones en la interfaz, formularios específicos de la aplicación).
Aquí las reglas de seguridad son más estrictas: entorno aislado, pasos verificados uno a uno, y nunca acciones irreversibles (envío, validación final) sin confirmación humana explícita. Un agente computer-use es, en la práctica, un agente de IA que usa el ordenador exactamente como lo haría una persona — mueve el ratón, lee la pantalla, pulsa teclas — allí donde no existe otra vía de acceso. Para tareas de tipo computer-use, donde el agente decide por su cuenta una larga serie de acciones en pantalla, explicamos por separado cuándo de verdad merece la pena el modelo de IA más avanzado disponible, frente al resto del volumen de trabajo habitual.
Qué hemos aprendido probando con datos reales
Las interfaces reales tienen sorpresas: menús bloqueados por configuraciones invisibles, códigos de error sin explicación, ventanas de diálogo que se renderizan mal. Un buen agente computer-use sabe diagnosticar estos bloqueos, no solo repetir la misma acción fallida.
Un ejemplo concreto: diagnosticar el motivo por el que un menú de una aplicación de contabilidad aparece bloqueado (un ajuste de configuración invisible en la interfaz estándar), resuelto leyendo directamente los ficheros de configuración, no por ensayo y error en pantalla. Hemos probado agentes de IA que usan el ordenador sobre interfaces reales, con menús bloqueados y ventanas de diálogo mal renderizadas, no solo en entornos de prueba controlados.
Diagnóstico primero, automatización después
Cada proyecto de este tipo empieza verificando qué es técnicamente posible, no dando por hecho que la interfaz se puede automatizar directamente. La automatización de aplicaciones de escritorio con IA siempre empieza con un diagnóstico técnico: comprobamos qué se puede leer directamente de los datos antes de proponer operar la interfaz.
- 01Comprobamos si existe una vía de lectura directa (preferible) o si hace falta interactuar con la interfaz
- 02Construimos el conector/agente, con reglas explícitas sobre qué puede hacer solo y qué necesita confirmación
- 03Probamos con datos y escenarios reales, incluyendo casos límite (errores, bloqueos, interfaces inesperadas)
- 04Entregamos con documentación sobre qué automatiza exactamente el sistema y qué sigue siendo manual
Precio fijo, tras un discovery breve.
- diagnóstico del sistema
- conector de solo lectura
- entrega + documentación
- mapeo de la interfaz
- agente + reglas de seguridad
- formación del equipo
- monitorización continua
- ajustes mensuales
- informe mensual
Cada proyecto tiene otro contexto, otros flujos y otra infraestructura, así que el precio se fija tras un discovery breve y de pago, y después no cambia por el camino.
Preguntas frecuentes
¿Qué es un agente computer-use?
Es un agente de IA que interactúa con una aplicación exactamente como lo haría una persona: ve la pantalla, hace clic, escribe, para sistemas que no ofrecen otra vía de integración (sin API, sin exportación automática). Se usa como último recurso, cuando la lectura directa de datos no es posible.
Automatización de software sin API: ¿es posible?
Sí, por dos vías: la lectura directa del formato nativo de datos (más robusta, preferible cuando es posible) o la operación controlada de la interfaz existente (computer-use, cuando no hay otra vía). Muchos sistemas de escritorio importantes en Rumanía funcionan así.
¿Es seguro dejar que un agente de IA opere una aplicación de escritorio?
Con reglas claras, sí: entorno aislado, pasos verificados y ninguna acción irreversible (envío, validación final, borrado) sin confirmación humana explícita. Sin estos límites, el riesgo es real; por eso siempre diseñamos separando estrictamente «lo que puede hacer solo» de «lo que requiere una persona».
¿Por qué no esperamos sin más a que aparezca una API?
Para algunos sistemas de escritorio importantes, la empresa fabricante ha confirmado oficialmente que las API siguen previstas solo para las versiones cloud/web, no para las de escritorio, sin fecha clara. Esperas indefinidamente una API que puede no llegar nunca para la versión que usas hoy.
¿Se puede escribir automáticamente de vuelta en el sistema origen (por ejemplo, contabilidad)?
Nuestra recomendación firme es que no — escribir directamente en los archivos de datos de un sistema puede corromper su integridad. Cualquier modificación pasa por el mecanismo oficial de importación/exportación que el sistema expone, aunque eso suponga un paso adicional.
¿Cuánto cuesta automatizar un sistema sin API?
Depende de si solo hace falta lectura (más simple, más barato) o la operación completa de la interfaz (más complejo).
¿Qué código CAEN cubre este tipo de automatización para una empresa en Rumanía?
La automatización y la integración de software a medida, incluidos los agentes computer-use, entran dentro del mismo código CAEN 6201 (el código de actividad económica rumano) que el desarrollo de software a medida.
Veamos qué se puede automatizar en tu empresa.
Una sesión gratuita de 30 minutos: te decimos qué se puede automatizar, cuánto se tarda y cuánto cuesta, con precio fijo tras el discovery.