La plataforma, instalada
en tu edificio.
Oria funciona de tu lado del muro, sobre tu ontología, en tus GPUs.
ARPIA Edge es el runtime que instalas en tu propio datacenter. Tu gente sigue usando Oria igual que en nuestra nube: pregunta, Oria razona sobre la ontología y la memoria institucional, y construye lo que hace falta. La diferencia es que ahora los datos, las llaves, la inferencia y el registro de auditoría nunca salen de tu infraestructura. Nosotros publicamos las aplicaciones desde nuestro lado; la ejecución, y todo lo que toca, queda del tuyo.
Los datos no pueden salir, y la transferencia no se puede justificar.
Si manejas historias clínicas, expedientes de clientes, casos o cualquier cosa protegida por secreto profesional, nadie te pregunta qué modelo usas. Te preguntan quién más podría leer el archivo, y bajo qué ley. Una transferencia internacional tiene que justificarse, y una región de hosting no la justifica: el operador de esa región sigue teniendo las llaves y la vía de acceso.
- Tu obligación es mantener los datos fuera de alcance. Tenerlos dentro de un país no alcanza.
- Un asistente que lee tus archivos tiene tu contexto, estén donde estén los servidores.
- Un compromiso de política solo se puede auditar como documento. Una arquitectura se puede auditar como sistema.
La Factory construye. El Edge ejecuta.
Una línea divide la plataforma en dos, y todo lo demás sale de ahí. Ejecutar un caso de uso gobernado baja a tu lado. Generarlo se queda arriba, con nosotros.
Factory, en nuestra nube
Donde se diseña un caso de uso: la ontología, el razonamiento, la generación de código, el flujo gobernado. Es nuestra ingeniería, y trabaja con datos de prueba. Nunca guarda tus datos de producción, porque nunca los necesita.
Edge, dentro de tus muros
Donde se ejecuta: sobre tus datos de producción, tus llaves, tu clúster. Ejecuta lo que produjo la Factory y no puede crear nada nuevo, y justo por eso puedes dejarlo cerca de los datos.
La asimetría es deliberada en ambos lados. Tú recibes un ejecutor que puedes inspeccionar, y al inspeccionarlo ves cómo corre un caso de uso, no cómo los construimos. Nosotros guardamos la parte difícil de construir, y la mantenemos lejos de tus datos. Ninguno tiene que confiarle al otro lo que no puede darse el lujo de perder.
Un runtime, cuatro piezas corriendo en tu clúster.
Edge es la parte de la plataforma que ejecuta, empaquetada para que tu equipo la instale y la opere en tu propio Kubernetes. No es una copia de la plataforma completa.
Oria, en local
La misma interfaz que tu gente ya usa, respondiendo desde tu ontología local y tu memoria institucional. Las sesiones, los artefactos y las apps en vivo se quedan adentro.
La ontología, residente
El modelo de tu negocio, guardado en local para que el runtime resuelva y ejecute sin llamarnos. Las aplicaciones la leen ahí mismo.
Ejecución e inferencia
El código gobernado corre en contenedores efímeros en tu clúster, y los modelos pueden correr en tus propias GPUs, así ningún prompt ni ningún registro llega a un proveedor.
El centro de actualizaciones
Donde tu administrador ve lo que publicamos, lee qué cambió, lo aplica, lo rechaza o vuelve atrás. También es la consola de administración local.
Lo que no instalas es la parte que construye. Esa se queda con nosotros, y por eso podemos entregarte el resto.
Publicamos desde nuestra nube. Llega como una versión que tú apruebas.
Una aplicación construida en ARPIA no es código que tengas que volver a desplegar a mano. Se empaqueta como una sola versión, se lleva a tu Edge y se aplica en una sola transacción: las aplicaciones, la ontología que necesitan, las acciones gobernadas y el código ejecutable, todo en el mismo paquete.
Tu equipo también sigue construyendo. Lo que un Builder crea en la plataforma baja por el mismo camino, así el runtime local y el trabajo de tu gente avanzan al mismo paso sin que nadie copie archivos entre ambientes.
- Una versión, un punto en el tiempo, aplicada completa o no aplicada.
- Si la aplicas dos veces, la segunda no cambia nada.
- Volver atrás es instalar la versión anterior. No hace falta un procedimiento de recuperación.
- Cada aplicación queda en tu propio registro de versiones, con lo que llegó y de dónde.
Cada pieza, y quién puede leerla.
Para esta conversación sirve más una lista de qué está dónde que un diagrama. Este es el diseño, línea por línea, incluida la línea que dice qué nos quedamos nosotros.
| Qué | Dónde vive | Quién puede leerlo |
|---|---|---|
| Datos de produccióntexto plano y llaves | Tu ambiente, en almacenamiento que tú controlas, cifrado con llaves que tú tienes. | Solo tú |
| Inferencia de modelosel razonamiento mismo | Tus propias GPUs, en local, así ningún prompt ni ningún registro se envía a un proveedor de modelos. La seudonimización solo importa si decides llamar a un modelo externo. | Solo tú |
| Logs y registro de auditoríaquién ejecutó qué, sobre qué | Tablas locales de tu lado, fuera del camino de entrega a propósito, así no pueden viajar ni por accidente. | Solo tú |
| Ontología y configuración de casos de usoel modelo de tu negocio | Se diseña en la Factory, se entrega de tu lado y se guarda en local para que el runtime funcione sin depender de nosotros. | Ambos |
| El motor de diseñocómo se construyen los casos de uso | Nuestra nube. Es nuestra ingeniería y se queda con nosotros, que es la otra mitad del acuerdo. | Solo nosotros |
Nada se actualiza solo.
Una soberanía que termina en la frontera de los datos es media respuesta. La otra mitad es quién decide cuándo cambia lo que corre sobre tus datos, y si después puedes probar qué cambió y cuándo.
- Ninguna versión se instala sola. Tu administrador la aplica, o no.
- Aplicar una es un evento de gobernanza de tu lado: qué versión, quién, cuándo.
- Quien aprueba lo que la IA puede hacer es alguien tuyo, en tu edificio.
- Rechazar una actualización es un estado soportado, no una falla. Puedes quedarte donde estás.
La persona que aprueba lo que la IA tiene permitido hacer también se queda de tu lado. Nada de ese paso viaja hacia nosotros, y por eso vale la pena tener a una persona en el circuito: la aprobación y su registro viven en el mismo lugar que los datos.
El resultado es un sistema cuyos cambios puedes reconstruir sin pedirnos nada.
La carga es real. Ya se movió entre datacenters.
El mecanismo del que depende este modelo ya existe fuera del diagrama. Un caso de uso completo, construido en uno de nuestros datacenters, se empaquetó, se llevó a otro y se aplicó ahí, a mano, de punta a punta. Esto es lo que lleva ese paquete y lo que garantiza:
- El código ejecutable viaja dentro de la versión, y no como una referencia a algo que se buscaría después.
- La ontología viaja con él, así lo que llega es lo que corre.
- Es una foto de un estado publicado, nunca una copia en vivo de lo que la fuente hacía en ese segundo.
- Te dice qué existe antes de escribir nada, y nombra los conflictos.
- Las identidades y las conexiones a sistemas se reescriben para el destino, así la copia que llega apunta a tus sistemas y no a los nuestros.
- Ambos lados guardan un registro: qué llegó, de dónde, con qué advertencias.
Esa es la parte que una evaluación técnica puede poner a prueba, así que es la parte con la que empezamos.
En tu jurisdicción, con un operador que está en ella.
Para trabajo regulado, la estructura más limpia evita el contrato con un proveedor extranjero. Licenciamos la plataforma a un operador establecido donde tú estás, que la opera sobre infraestructura en tu país y tiene la relación contigo. Nosotros somos el licenciante de la tecnología, sin custodia de tus datos y sin una vía de acceso propia a ellos.
La continuidad está escrita en la licencia. Si el soporte llegara a terminar, el derecho a seguir operando el runtime sigue vigente.
- Tu contraparte es local, y la infraestructura también.
- No tenemos copia de tus datos ni llave para leerlos.
- El runtime sigue funcionando aunque la relación comercial termine.
Trae tu restricción.
Cuéntanos qué no pueden hacer tus datos y qué autoridad lo dice. En treinta minutos te decimos si esta arquitectura lo resuelve, y dónde todavía no.