Por qué distribuimos IA como binarios instalables, no como SaaS en la nube
Inferencia local, auditoría controlada por el cliente y un proceso de compra que ya existe. Tres razones estructurales por las que los productos de IA de Software Tailor son instaladores de escritorio y no un tenant en nuestra nube.
La mayor parte de la gama AI Suite se instala en la propia máquina del usuario. No hay tenant. No hay un inicio de sesión en la nube que controle el acceso al motor de inferencia. Las aplicaciones de escritorio se comunican con un proceso local aisuite-server que, a su vez, se comunica con un modelo en el propio dispositivo o con un AI Server controlado por el cliente que se ejecuta dentro de la red del cliente. Esa elección —instalador de escritorio, no SaaS— es deliberada, y vale la pena dejar por escrito las razones.
Razón 1: los compradores regulados no pueden poner prompts de producción en la nube de otro
La EU AI Act, en vigor desde 2024, clasifica un conjunto significativo de flujos de trabajo empresariales como «de alto riesgo» e impone al deployer obligaciones de mantenimiento de registros, supervisión humana y tratamiento de datos [1]. Marcos equivalentes o paralelos existen en los Estados miembros de la OCDE [2], y las agencias federales de EE. UU. operan conforme al NIST AI Risk Management Framework al adquirir sistemas de IA [3]. Ninguno de estos marcos prohíbe la IA en la nube; exigen que el deployer pueda demostrar, en tiempo real y por solicitud, qué se envió a dónde y qué se recibió de vuelta.
En la práctica, ese requisito choca con la forma en que funcionan hoy las APIs LLM en la nube. Un responsable de cumplimiento de una farmacéutica no puede extraer un rastro de auditoría por prompt de un SaaS de terceros para un flujo que procesa identificadores de pacientes, incluso cuando el SaaS está contractualmente alineado con el RGPD. Necesita que el prompt y la respuesta nunca salgan de una red que ellos posean. La forma más limpia de dárselo es distribuir la IA como un binario que el cliente ejecuta dentro de su propio perímetro, que es lo que hacemos.
No se trata de un comprador hipotético. La cohorte de clientes a la que hemos entregado desde 2007 incluye seis organizaciones Fortune Global 500 en farma, finanzas, gobierno, jurídico, defensa y energía [4]. Cada uno de esos sectores tiene al menos un flujo de trabajo en el que la respuesta a «¿dónde ocurre la inferencia?» decide si la conversación de compras siquiera empieza.
Razón 2: un binario instalable encaja con la forma en que las empresas compran software de verdad
El proceso de compra para una aplicación de escritorio está bien entendido en las grandes organizaciones de TI. La aplicación se empaqueta, se distribuye a través de SCCM, Intune o Jamf, se gobierna mediante las mismas políticas de grupo que Microsoft Office, y se desinstala cuando se retira el portátil. Compras, revisión de seguridad y la unidad de end-user computing tienen procesos con décadas de antigüedad para esto. AI Suite encaja directamente.
El SaaS en la nube, por el contrario, requiere un proceso paralelo: una revisión de riesgo de proveedor por cada tenant, una conversación de federación de identidades, auditorías continuas de la postura del proveedor y una negociación constante sobre a qué obligación le toca cada parte cuando algo falla. Útil para algunos tipos de software. Mal encaje para los flujos de trabajo de IA que nuestros clientes están construyendo.
Al distribuir aplicaciones instalables que se autentican contra el propio proveedor de identidad del cliente —Microsoft Entra ID o Google Workspace mediante OpenID Connect— y que no almacenan nada en nuestros servidores más allá del directorio de la organización y el registro de auditoría de acciones administrativas, situamos la conversación de compras dentro del marco que esta ya sabe gestionar.
Razón 3: cero fracasos de proyecto desde 2007 depende de no depender del uptime de otro
Hemos entregado software personalizado durante diecinueve años con un historial de cero fracasos de proyecto desde 2007 [4]. Ese historial existe porque el equipo controla cada capa de la entrega: código, build, test, artefacto de despliegue. En el momento en que hacemos que el flujo de trabajo de producción de un cliente dependa de que la nube de otra empresa siga disponible, ese historial deja de ser nuestro para defenderlo.
Los proveedores de IA en la nube tienen caídas. Aplican throttling. Cambian precios. Retiran modelos. Retiran APIs enteras. Los clientes a los que damos servicio en farma y defensa no pueden permitirse que su expediente regulatorio de un año se atasque porque un endpoint de modelo que no controlan haya sido migrado. Así que no los ponemos en uno. El modelo vive en la máquina del cliente, la inferencia ocurre en la máquina del cliente, y lo único en nuestra infraestructura es la ligera superficie de administración que utilizan para gestionar su propio despliegue.
Qué significa esto para la evaluación
Si usted es responsable de cumplimiento, CIO o CTO evaluando IA local para un despliegue empresarial, las preguntas relevantes se ven distintas a las de una evaluación de SaaS en la nube:
- ¿Dónde ocurre la inferencia? En el dispositivo del usuario o en un servidor que el cliente controla. No en el nuestro.
- ¿Qué sale del perímetro? Solo el directorio de la organización y las acciones administrativas. Ningún prompt, ninguna respuesta, ningún contenido de documentos.
- ¿Cuál es el rastro de auditoría? JSONL sin contenido, almacenado localmente y exportable. El modelo nunca ve contenido sobre el que no se le indique actuar, y la fila de auditoría nunca ve contenido alguno.
- ¿Qué pasa cuando el proveedor desaparece? Los binarios que el cliente instaló siguen funcionando. El AI Server local que dieron de alta sigue sirviendo. No se requiere re-plataformización.
Esas son las cuatro preguntas para las que construimos AI Admin Console y Local AI Suite con el fin de responderlas con claridad. El artículo sobre cumplimiento de la EU AI Act y despliegue on-premises aborda la parte regulatoria con más detalle.
Referencias
- European Commission. «AI Act — Regulatory framework on AI.» digital-strategy.ec.europa.eu. Consultado el 2026-06-15.
- OECD AI Policy Observatory. «National AI policies.» oecd.ai. Consultado el 2026-06-15.
- NIST. «AI Risk Management Framework (AI RMF 1.0).» nist.gov/itl/ai-risk-management-framework. Consultado el 2026-06-15.
- Software Tailor. «Past clients.» softwaretailor.com/past-clients.htm. Consultado el 2026-06-15.
Artículos relacionados
Evalúe el mismo enfoque sobre una carga de trabajo real.
Un piloto gratuito de 1 semana recorre una pieza real del trabajo del cliente: inferencia local, identidad controlada por el cliente y auditoría controlada por el cliente.