La mayoría de la línea AI Suite se instala en la propia máquina del usuario. No hay inquilino. No hay inicio de sesión en la nube que limite el acceso al motor de inferencia. Las aplicaciones de escritorio se comunican con un aisuite-server proceso que, a su vez, se conecta ya sea a un modelo en el dispositivo o a un AI Server controlado por el cliente y ejecutándose dentro de la red del cliente. Esa elección — instalador de escritorio, no SaaS — es deliberada, y las razones merecen ser documentadas.

Razón 1: los compradores regulados no pueden poner indicaciones de producción en la nube de terceros

La Ley de IA de la UE, vigente desde 2024, clasifica un conjunto sustancial de flujos de trabajo empresariales como "de alto riesgo" e impone obligaciones de registro, supervisión humana y manejo de datos al implementador [1]. Existen marcos equivalentes o paralelos en los estados miembros de la OCDE [2], y las agencias federales de EE. UU. operan conforme al Marco de Gestión de Riesgos de IA de NIST al adquirir sistemas de IA [3]. Ninguno de estos marcos prohíbe la IA en la nube; requieren que el implementador pueda demostrar, de forma contemporánea y bajo solicitud, qué se envió dónde y qué se recibió.

En la práctica, ese requisito choca con el funcionamiento actual de las API de LLM en la nube. Un responsable de cumplimiento farmacéutico no puede obtener un historial de auditoría por indicación de un SaaS de terceros para un flujo de trabajo que procesa identificadores de pacientes, incluso cuando el SaaS cumple contractualmente con el GDPR. Puede que necesiten que la indicación y la respuesta nunca salgan de una red que poseen. La forma más limpia de proporcionar ese camino es distribuir la IA como un binario que el cliente ejecuta dentro de su propio perímetro — que es lo que hacemos.

Este no es un comprador hipotético. La cohorte de clientes a la que hemos distribuido desde 2007 incluye seis organizaciones Fortune Global 500 en sectores como farmacéutico, financiero, gubernamental, legal, defensa y energía [4]. Cada uno de esos sectores tiene al menos un flujo de trabajo donde la respuesta a "¿dónde ocurre la inferencia?" decide si la conversación de adquisición siquiera comienza.

Razón 2: un binario instalable coincide con la forma en que las empresas realmente compran software

El proceso de compra para una aplicación de escritorio está bien entendido dentro de grandes organizaciones de TI. La aplicación se empaqueta, distribuye mediante SCCM, Intune o Jamf, se rige por las mismas políticas de grupo que Microsoft Office, y se elimina cuando se da de baja el portátil. Compras, revisión de seguridad y computación para el usuario final tienen procesos con décadas de antigüedad para esto. AI Suite encaja directamente.

El SaaS en la nube, en cambio, requiere un proceso paralelo: revisión de riesgo del proveedor por inquilino, conversación de federación de identidad, auditorías continuas de la postura del proveedor y una negociación constante sobre qué obligaciones cubre quién cuando algo falla. Útil para algunos tipos de software. Mala opción para los flujos de trabajo de IA que nuestros clientes están construyendo.

Al distribuir aplicaciones instalables que pueden autenticarse con el propio proveedor de identidad del cliente — Microsoft Entra ID o Google Workspace vía OpenID Connect — mantenemos el contenido de inferencia fuera del plano de control de Software Tailor. Los servicios de la organización aún procesan los registros necesarios para operar la implementación: listas y roles, derechos, políticas y estado del servidor, uso agregado, auditoría administrativa, licencias y soporte. Esos son registros reales del lado del proveedor, pero están separados de las indicaciones, respuestas y documentos del cliente en la ruta del modelo local o alojado por el cliente.

Razón 3: cero fallos en proyectos desde 2007 depende de no depender del tiempo de actividad de terceros

Hemos entregado software personalizado durante diecinueve años con un récord de cero fallos en proyectos desde 2007 [4]. Ese récord existe porque el equipo controla cada capa de la entrega: código, compilación, pruebas, 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 esté disponible, ese récord deja de ser nuestro para defender.

Los proveedores de IA en la nube tienen interrupciones. Limitan el uso. Cambian precios. Retiran modelos. Retiran APIs completas. Los clientes a los que servimos en farmacéutica y defensa no pueden permitir que su caso regulatorio de un año se detenga porque un endpoint de modelo que no poseen fue migrado. Por eso no ponemos su ruta de modelo local en uno. El modelo vive en el equipo del cliente y la inferencia ocurre en el equipo del cliente. Nuestra infraestructura suministra los servicios del plano de control necesarios para identidad, derechos, políticas, estado de la flota, uso agregado, administración y soporte; no es el entorno de ejecución de inferencia y no recibe contenido de indicaciones ni respuestas en esa ruta.

Qué significa esto para la evaluación

Si eres responsable de cumplimiento, CIO o CTO evaluando IA local para un despliegue empresarial, las preguntas relevantes son diferentes a una evaluación de SaaS en la nube:

  • ¿Dónde ocurre la inferencia? En el dispositivo del usuario o en un servidor que controla el cliente. No en el nuestro.
  • ¿Qué sale del perímetro? En la ruta de inferencia local o alojada por el cliente, no se envían indicaciones, respuestas ni contenidos de documentos a Software Tailor. Los registros de plano de control, licencias, seguridad, telemetría (cuando está habilitada) y soporte tienen rutas de datos documentadas y separadas.
  • ¿Cuál es la pista de auditoría? JSONL sin contenido, almacenado localmente, exportable. El modelo nunca ve contenido sobre el que no se le haya indicado actuar, y la fila de auditoría nunca ve contenido alguno.
  • ¿Qué sucede cuando el proveedor desaparece? Los binarios instalados y el entorno de ejecución local gratuito no dependen de un inquilino de inferencia alojado. La suscripción, la organización y las capacidades Pro gestionadas centralmente aún pueden depender de derechos válidos y servicios del plano de control, por lo que un plan de salida debe tenerlos en cuenta.

Esas son las cuatro preguntas que construimos AI Admin Console y la Local AI Suite para responder claramente. El artículo sobre cumplimiento del EU AI Act y despliegue on-premise cubre el lado regulatorio con más profundidad.

Referencias

  1. Comisión Europea. "Ley de IA — Marco regulatorio sobre IA." https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Consultado el 15-06-2026.
  2. Observatorio de Políticas de IA de la OCDE. "Políticas nacionales de IA." https://oecd.ai/. Consultado el 15-06-2026.
  3. NIST. "Marco de Gestión de Riesgos de IA (AI RMF 1.0)." https://www.nist.gov/itl/ai-risk-management-framework. Consultado el 15-06-2026.
  4. Software Tailor. "Clientes anteriores." https://softwaretailor.com/past-clients.htm. Consultado el 15-06-2026.