Inteligencia artificial para Un sistema sin API

Una parte grande de las pymes argentinas trabaja con sistemas que no publican ninguna API: un desarrollo a medida que hizo un programador conocido hace quince años en Visual FoxPro o Delphi, un sistema de nicho para farmacias, ferreterías o acopios, una versión vieja de un ERP conocido que nunca se actualizó. La pregunta "¿y si mi sistema no tiene API?" es la primera que aparece cuando alguien escucha hablar de agentes de IA conectados a la gestión.

La respuesta corta: casi siempre se puede igual, porque la API es solo una de las puertas. Todo sistema guarda sus datos en algún lado, y ese lugar suele ser una base de datos conocida (SQL Server, MySQL, Firebird, PostgreSQL, Access) o, en el peor caso, archivos DBF. Y todo sistema que sirva para algo imprime o exporta listados. Con una de esas dos cosas alcanza para que un agente responda qué se vendió, quién debe y qué falta en stock.

Lo que sigue describe las tres vías posibles, qué hace falta para cada una, y en qué casos no hay solución honesta: bases cifradas, sistemas de nube cerrados o licencias que prohíben tocar la base.

Vía 1: lectura directa de la base de datos. Se crea un usuario de solo lectura en el motor (en SQL Server, un login con el rol db_datareader; en MySQL o PostgreSQL, un usuario con permiso SELECT; en Firebird, un rol con grants de lectura; en Access, se trabaja sobre una copia del archivo .mdb o .accdb) y el agente consulta las tablas. Es la vía más completa, porque llega a todo el historial con el detalle original, y la más común en sistemas instalados en un servidor propio. Exige dos cosas: entender el modelo de datos (las tablas suelen llamarse FACCAB, STKMOV o peor, y eso se releva una vez con quien conozca el sistema) y que el servidor sea alcanzable, por VPN o con un conector instalado en la misma red. En sistemas DBF o con bases cifradas por el proveedor esta vía no está disponible.

Vía 2: exportaciones programadas. Si el sistema exporta listados a Excel o CSV (ventas por período, saldos de clientes, stock valorizado), esa exportación se programa: una tarea de Windows, una macro o una persona cada mañana la deja en una carpeta compartida (Drive, OneDrive) o la envía por correo a una casilla, y el agente lee el archivo más nuevo. Es la vía que funciona con sistemas de nube cerrados y con proveedores que no permiten tocar la base. El límite es el que tenga el listado: solo las columnas que incluye, con la frecuencia con que se exporta, sin el detalle que el informe resume.

Vía 3: conector de lectura que replica tablas. Un programa chico se instala en el servidor del sistema, lee las tablas (o las exportaciones) con el usuario de solo lectura y copia los cambios, cada pocos minutos, a una base fuera de la empresa que es la que consulta el agente. No abre ningún puerto hacia internet, no carga el sistema con consultas pesadas y deja el historial disponible aunque el servidor esté apagado. Es la forma en que Pulso trabaja con Time, por ejemplo. Lo que no resuelve ninguna de las tres vías: una base cifrada con contraseña del proveedor, un sistema de nube sin exportación ni API, o un contrato de licencia que prohíba el acceso a los datos; en esos casos lo decimos en la primera llamada.