01
Elegid la frontera que necesita
Ejecutad Kordon en vuestra propia infraestructura cuando necesitéis un control más estricto sobre la ubicación de los datos, las rutas de acceso, la exposición de red o la política interna de alojamiento.
GRC On-Premises
Plataforma GRC On-Premises
Kordon puede ejecutarse en vuestra propia infraestructura cuando la política, las fronteras de datos o los requisitos de implantación descartan el SaaS alojado por el proveedor. Si está evaluando una plataforma de GRC on-premises, sigue obteniendo el mismo sistema conectado para riesgos, controles, tareas, evidencias, activos, proveedores y procesos de negocio.
Cómo funciona
Del requisito de implantación a un programa de seguridad activo
El objetivo del GRC on-premises no es solo dónde reside el software. Es si el sistema sigue haciendo que el trabajo de seguridad y cumplimiento normativo sea operacional una vez que está dentro de vuestro entorno.
02
Mapead vuestro contexto operativo real
Documentad los activos, proveedores, procesos de negocio, riesgos y requisitos de framework que realmente importan para vuestra organización en lugar de forzar todo en una plantilla genérica.
03
Conectad los controles a la ejecución
Vinculad cada control a los riesgos que mitiga y a los requisitos que satisface, luego operacionalizadlo mediante tareas recurrentes a cargo de las personas responsables del trabajo.
04
Mantened el flujo de evidencias de forma continua
A medida que se completan las tareas, las evidencias se acumulan y los auditores obtienen trazabilidad clara. La plataforma refleja si el programa avanza según lo diseñado o está derivando.
Diseñado para entornos con restricciones
Una plataforma de GRC on-premises sin las concesiones habituales
La implantación on-premises debería cambiar dónde se ejecuta la plataforma, no lo que la plataforma puede hacer. Kordon mantiene el mismo modelo operativo tanto si lo aloja en vuestro propio entorno como si usa nuestra implantación en la nube.
Ejecútelo en vuestra propia infraestructura
Implantad Kordon dentro del entorno que vosotros controláis cuando la política interna de alojamiento, la segmentación de red o los requisitos de los clientes hacen que el SaaS alojado por el proveedor no sea una opción adecuada.
Un sistema integrado
Riesgos, controles, requisitos, tareas, evidencias, activos, proveedores y procesos de negocio permanecen conectados en un único lugar en lugar de dispersarse en hojas de cálculo y carpetas.
Los controles se convierten en trabajo operacional
Kordon transforma políticas y controles en tareas recurrentes, responsabilidades, recordatorios y evidencias para que el programa siga funcionando dentro de vuestro entorno en lugar de convertirse en documentación estática.
Adapte la plataforma a vuestro modelo
Usad campos personalizados, etiquetas, permisos y estructura que reflejen cómo opera realmente vuestra organización en lugar de remodelar vuestro programa en torno al esquema predeterminado de un proveedor.
Incorporad a más personas al programa
Dad a los responsables de controles, responsables de riesgos, auditores y partes interesadas operacionales visibilidad y responsabilidad claras sin convertir al equipo de seguridad en un cuello de botella de documentación.
Mantened sus integraciones
El acceso a la API y la automatización siguen siendo importantes on-premises. Conectad Kordon al resto de vuestra cadena de herramientas y mantened la recopilación de evidencias, los flujos de trabajo y los informes integrados en vuestro entorno.
Implantación
Qué cambia cuando lo alojáis vosotros y qué no
La residencia de datos suele ser lo que trae a esta página, y las dos formas de implantar Kordon responden a ello: la plataforma alojada funciona en Finlandia o Alemania, o ejecutáis todo vosotros mismos. En muchos proveedores la edición autoalojada es una versión recortada, una entrega por detrás de la alojada o con integraciones que vuelven discretamente por la nube del proveedor. Kordon cambia el destino de la implantación y nada más.
| Kordon Cloud | Vuestra propia infraestructura | |
|---|---|---|
| Dónde residen físicamente los datos | Kordon CloudEn la UE, en el país que elijáis. Escogéis Finlandia o Alemania al crear la cuenta y los datos permanecen en esa región. | Vuestra propia infraestructuraDonde vosotros los pongáis. La residencia de datos deja de ser algo que tengáis que creer bajo palabra del proveedor. |
| Modelo de objetos, interfaz, permisos | Kordon CloudPlataforma completa | Vuestra propia infraestructuraLa misma plataforma, en la misma versión |
| API REST y nodo de n8n | Kordon CloudAPI completa, nodo oficial de n8n | Vuestra propia infraestructuraLa misma API, el mismo nodo. Ninguna capacidad queda reservada para la edición alojada. |
| Sobre qué se ejecuta | Kordon CloudSobre nada. Lo operamos nosotros. | Vuestra propia infraestructuraUn contenedor Docker sobre infraestructura Linux estándar, configurado mediante variables de entorno |
| HTTPS | Kordon CloudGestionado | Vuestra propia infraestructuraIntegrado en el contenedor, de modo que no hay que levantar un proxy inverso aparte |
| Inicio de sesión único | Kordon CloudGoogle Workspace, Microsoft Entra, Okta, Keycloak | Vuestra propia infraestructuraLos mismos cuatro, integrados en el contenedor, sin necesidad de un servicio de autenticación aparte |
| Aprovisionamiento automático de usuarios | Kordon CloudSCIM 2.0 con Entra, Okta, OneLogin y Google Workspace | Vuestra propia infraestructuraIgual |
| Dónde se guardan los archivos de evidencias | Kordon CloudGestionado por nosotros | Vuestra propia infraestructuraSistema de archivos local, Google Cloud Storage o AWS S3, en un bucket vuestro |
| Contenido de marcos normativos | Kordon CloudISO 27001, SOC 2, NIS2, DORA, E-ITS, ISO 9001, ISO 14001 y cientos de normas más precargadas, además de vuestros marcos internos como requisitos personalizados | Vuestra propia infraestructuraLa misma biblioteca, precargada. Un control puede cubrir requisitos de varios marcos a la vez. Cómo funciona la gestión de marcos normativos → |
| IA y agentes | Kordon CloudTraed vuestro propio agente. No hay ningún modelo incrustado en la plataforma. Los agentes se conectan por la API REST, el nodo oficial de n8n y habilidades creadas para Kordon, con el framework con el que ya trabajéis. Cómo funciona el GRC con agentes → | Vuestra propia infraestructuraIdéntico, y es lo que mantiene intacta la frontera: como el modelo nunca está dentro de la plataforma, vuestro agente y su cómputo pueden estar donde os haga falta, incluido hardware dentro de vuestra propia red |
| Actualizaciones, copias de seguridad, disponibilidad, capacidad | Kordon CloudResponsabilidad nuestra | Vuestra propia infraestructuraVuestra, según vuestro propio calendario de cambios |
Preguntas frecuentes
Residencia de datos y autoalojamiento
¿Necesitamos on-premises para mantener los datos en la UE?
A menudo no, y conviene comprobarlo antes de asumir la carga operativa. Kordon Cloud funciona en la UE y elegís Finlandia o Alemania al crear la cuenta. Si vuestro requisito pide una región de la UE identificada bajo el RGPD, la cuestión queda resuelta ahí. El autoalojamiento es la respuesta cuando el requisito va más allá de la geografía. Ocurre con una política nacional de alojamiento que exija vuestra propia infraestructura, con una norma sectorial sobre quién puede custodiar los datos, con un contrato de cliente que descarte entornos compartidos, o con un consejo que no acepte un SGSI en la nube de otra empresa. Las dos rutas ejecutan la misma plataforma, así que es una cuestión sobre vuestras obligaciones y no sobre qué producto recibís. Una comprobación para cualquier proveedor que prometa residencia en la UE: si la región del material comercial es la misma que aparece en la URL, y si sus funciones de IA se quedan dentro de ella.
¿La versión on-premises es una edición reducida de la plataforma?
No. Es la misma aplicación que la versión alojada: el mismo modelo de objetos, la misma API REST completa, el mismo nodo oficial de n8n, el mismo modelo de permisos y la misma biblioteca precargada de marcos normativos, que cubre ISO 27001, SOC 2, NIS2, DORA, E-ITS, ISO 9001, ISO 14001 y cientos de normas más, además de cualquier marco interno que añadáis como requisitos personalizados. El autoalojamiento es una decisión de implantación, no un nivel de producto. Conviene preguntarlo a cualquier proveedor: es habitual que la edición autoalojada vaya una entrega por detrás, o que sus integraciones pasen discretamente por la nube del proveedor, lo que anula el motivo de haber desplegado dentro de vuestra frontera.
¿Qué infraestructura tenemos que aportar?
Un entorno Linux capaz de ejecutar un contenedor Docker y un sitio donde guardar los archivos de evidencias. Toda la configuración se hace mediante variables de entorno, TLS viene integrado en el contenedor, de modo que no hace falta un proxy inverso aparte, y el almacenamiento de evidencias puede apuntar al sistema de archivos local, a Google Cloud Storage o a AWS S3. Kordon usa paginación y filtrado en servidor, así que sigue respondiendo con decenas de miles de activos y tareas.
¿Dónde ocurre el procesamiento de IA en una implantación autoalojada?
Donde vosotros decidáis. Kordon está construido para que traigáis vuestro propio agente: no hay ningún modelo incrustado en la plataforma. Los agentes se conectan por la API REST completa, el nodo oficial de n8n y habilidades creadas para Kordon, y sirve cualquier framework, ya sea Claude, LangChain, n8n o algo que haya escrito vuestro propio equipo. Como no tenemos modelo propio al que enviarlo, nada saca vuestras evidencias fuera por defecto: apuntáis un agente a un modelo que corre en vuestro hardware y el cómputo se queda en la misma frontera que los datos, con los mismos permisos que rigen para vuestras personas. Esta es la pregunta que conviene hacer a cualquier proveedor de GRC en una revisión de residencia, porque es donde suelen romperse las promesas. Una plataforma puede estar en vuestra región y aun así enviar cada documento que procesa a un modelo situado en otro sitio. Preguntad dónde ocurre el cómputo, no solo dónde está la base de datos.
¿Quién aplica las actualizaciones y con qué calendario?
Vosotros, según vuestro propio calendario de cambios, que suele ser justamente el motivo del autoalojamiento. Conviene preguntar a cualquier proveedor cuánto tiempo se mantiene una entrega autoalojada, porque una plataforma que nadie actualiza se convierte en un hallazgo de auditoría propio en un par de años.
¿Podemos empezar en Kordon Cloud y pasar después a nuestra infraestructura?
Sí. Como las dos implantaciones ejecutan la misma aplicación sobre el mismo modelo de objetos, el programa que construís en una es el que ejecutáis en la otra. Podéis empezar alojados mientras aún estáis dando forma a vuestro conjunto de controles y al alcance de los marcos, y trasladarlo después cuando un requisito de cliente, un regulador o una política interna de alojamiento convierta la frontera en algo firme.
¿Una implantación on-premises admite SSO y aprovisionamiento automático?
Sí, y sin piezas añadidas. El inicio de sesión único para Google Workspace, Microsoft Entra, Okta y Keycloak viene integrado en el contenedor de Kordon, en lugar de requerir una instancia de Keycloak o un servicio de autenticación aparte, y el aprovisionamiento SCIM 2.0 funciona con Entra, Okta, OneLogin y Google Workspace. Los usuarios se crean y se desactivan en Kordon automáticamente según cambian en vuestro proveedor de identidad.
¿Para quién es realmente el GRC on-premises?
Para equipos cuya frontera de implantación la fija otro: un regulador, una política nacional de alojamiento, el cuestionario de seguridad de un cliente, o un consejo que no acepte un SGSI en la nube de otra empresa. Eso es distinto de preferir el autoalojamiento. Si ya operáis vuestra propia infraestructura y tenéis el equipo para mantenerla, alojar ahí una plataforma de GRC no es una carga añadida que asumís, es el entorno en el que ya trabajáis. Y si no, Kordon Cloud es la misma plataforma sin el peso operativo.