Confianza y cumplimiento
Decide una persona. El registro dice quién.
Qué puede hacer nuestro software por su cuenta, dónde se ejecuta y qué deja por escrito. Cada sección termina con enlaces a la documentación pública que lo demuestra, para que pueda comprobar cada línea en lugar de fiarse de nuestra palabra.
1 · Decide una persona
Los agentes redactan. Decide una persona con nombre.
Los agentes de Runink leen registros y redactan borradores: un expediente de siniestro, una corrección de código, una publicación, una respuesta. El borrador espera. Una persona con nombre lo aprueba, lo edita o lo rechaza, y el registro guarda quién fue y cuándo.
En Runink TIDE, esas decisiones se anotan en una cadena de auditoría. Cada entrada está enlazada con la anterior, así que una entrada modificada, eliminada o cambiada de orden se nota. Cualquier persona que haya iniciado sesión en la consola de TIDE puede pulsar Verify now para que se compruebe toda la cadena. Leer las entradas en sí queda reservado a los administradores que usted designe.
Hay dos cosas que actúan por su cuenta, y preferimos que lo lea aquí antes que descubrirlo después:
- FACE cuida de su propio funcionamiento. Cuando una parte de FACE deja de responder, puede reiniciarla, aislar una dependencia que falla una y otra vez, revertir el cambio más reciente o añadir capacidad. Solo elige de esa lista fija. Nunca borra datos, nunca apaga una máquina y nunca desactiva un control de seguridad. Si tiene dudas, avisa a una persona en lugar de actuar. Un operador puede desactivar la parte automática.
- El clasificador de incidencias de TIDE etiqueta las incidencias nuevas. Solo elige entre las etiquetas que el repositorio permite, y solo cuando una comprobación independiente está de acuerdo. Una persona puede cambiarlas en cualquier momento, y decide quién se encarga de la incidencia.
Todo lo demás espera a una persona.
2 · Salvaguardas
Cada agente trabaja dentro de reglas escritas.
Cada agente que llama a un modelo tiene delante un juez de políticas. El juez revisa una petición frente a reglas escritas antes de que el modelo la vea, y revisa lo que escribe el agente antes de que se envíe o se publique. Una petición que incumple una regla se rechaza, y el rechazo queda registrado.
Las reglas de seguridad siguen el OWASP Top 10 for LLM Applications, la lista publicada de las formas más habituales de atacar una aplicación de IA. Cubren los intentos de saltarse las instrucciones del agente (la inyección de prompt), los intentos de sacar secretos u otra información sensible y las peticiones de llegar a sitios donde el agente no tiene nada que hacer.
Los registros, las páginas web y los documentos que lee un agente se tratan como datos, nunca como instrucciones. Una línea de un registro de carga que dice «ignora tus reglas» se lee como parte de ese registro. Cuando un agente propone una acción, una segunda comprobación lee las pruebas que reunió la ejecución. Si no está de acuerdo, la acción se retiene. Si no puede decidir, lo dice en lugar de dejarla pasar.
3 · Dónde se ejecutan los modelos
Modelos abiertos, con nombre, sin un proveedor de IA de por medio.
FACE, TIDE y PULSE ejecutan sus modelos donde se ejecuta el producto. Si lo instala en un Runink Server en sus instalaciones o en su propia cuenta en la nube, los modelos también se ejecutan en su infraestructura. Si elige las máquinas compartidas de Runink, se ejecutan en las nuestras. En ambos casos no se llama a ningún servicio de IA de terceros: sus registros, los prompts construidos a partir de ellos y las respuestas no van a ningún proveedor de modelos.
LUNA, nuestra aplicación de compañía personal, ejecuta sus modelos en servidores que opera Runink. Tampoco llama a ningún servicio de IA de terceros.
Los modelos son abiertos, y los nombramos con su autor y su licencia:
Qwen3.6-35B-A3B
El modelo general, que usan la mayoría de los agentes. Creado por Qwen, con licencia Apache-2.0.
Qwen3-Coder-30B-A3B
El modelo de código, para revisar y redactar código. Creado por Qwen, con licencia Apache-2.0.
Qwen3-VL-8B-Instruct
El modelo de visión, para páginas escaneadas y fotografías. Creado por Qwen, con licencia Apache-2.0.
Cada agente tiene una ficha de modelo pública: qué hace, qué lee, qué sigue decidiendo una persona, en qué modelo se ejecuta, dónde se ejecuta y dónde se detiene.
4 · Sus datos, por separado
¿El registro de otra persona? «No encontrado».
Los datos de cada persona, y los de cada cliente, se mantienen separados en el servidor. A qué datos puede llegar una petición depende de la identidad comprobada al iniciar sesión, no de lo que diga la propia petición.
Pida un registro que pertenece a otra persona y la respuesta es «no encontrado», la misma que para un registro que no existe. La respuesta ni siquiera confirma que el registro esté ahí.
FACE va un paso más allá: cada cliente tiene su propia instancia de FACE, de modo que los datos de un cliente nunca comparten instancia con los de otro.
Lea las pruebas (en inglés)
5 · Desconocido no es cero
Una cifra que falta se muestra como que falta.
Cuando nuestro software no ha podido leer una cifra, lo dice, con el motivo. No dibuja un cero y no adivina. Una comprobación que no pudo ejecutarse figura como «no comprobado», nunca como superada. Un campo que desconoce se queda vacío, no se rellena.
Nos aplicamos la misma regla. Esta página no lleva estadísticas, y las fichas de modelo tampoco: ninguna muestra una puntuación de evaluación, porque no se ha publicado ninguna.
6 · Versiones firmadas
Una persona firma cada versión, lejos de la compilación.
Las versiones y los paquetes de Runink River se firman con una única clave de publicación. El responsable de versiones guarda la clave privada fuera de línea. Nunca está en la CI y nunca se guarda como secreto de un repositorio.
Las máquinas de compilación solo producen archivos sin firmar y sus sumas de comprobación. El responsable los compara con una compilación propia y después firma. Antes de que se publique una versión, un paso automático comprueba la firma y las sumas de comprobación. La CI verifica; nunca firma.
El archivo KEYS público es la referencia. Compruebe la clave por esta huella, nunca por su nombre:
95C0 A7B9 7D54 7413 E426 60DD B06F E756 26F1 5BF3
7 · Las normas con las que nos alineamos
Nuestros propios controles, relacionados con cinco normas.
Llevamos un índice escrito de nuestros propios controles de seguridad: cómo se cifran los datos en tránsito y en reposo, cómo el inicio de sesión deniega por defecto, cómo se mantienen separados los datos de cada cliente, cómo se gestionan los secretos, entre otros. Cada control señala el código que lo lleva a cabo, y cada uno está relacionado con los apartados de estas normas que aborda:
- SOC 2
- ISO/IEC 27001
- ISO 31000
- ISO/IEC 42001
- PCI DSS v4.0
Runink no está certificada en ninguna de estas normas; alinearse no es certificarse.
Un agente de evidencias lee el índice y comprueba que el código que señala cada control sigue ahí. Registra evidencias, nunca un veredicto. Cualquier declaración formal respecto de una de estas normas vendría de un auditor independiente, no de nosotros ni de nuestro software.
Lea las pruebas (en inglés)
8 · Informar de un problema de seguridad
¿Ha encontrado algo? Díganoslo en privado.
Por favor, no abra una incidencia pública por un problema de seguridad. Escriba a:
security@runink.org
Puede abrirla en su programa de correo, o copiar la dirección de arriba. Para cifrar su informe, use la clave de publicación de la sección 6 y compruebe antes su huella. Díganos qué está afectado y en qué versión, qué podría hacer un atacante y cómo reproducirlo si puede. Para Runink River, también puede usar el botón de informe privado de la pestaña Security del repositorio.
Lea las pruebas (en inglés)
Con quién trabajaría
Runink está dirigida por su fundador. La persona que está en la primera reunión es la que diseñó aquello de lo que se habla.
Dan Paes
Director ejecutivo y fundador técnico
Dan Paes ha pasado más de veinte años dentro de empresas ajenas, dirigiendo programas de transformación digital y de modernización a gran escala para organizaciones globales. Del tipo largo: lo que se sustituye es aquello sobre lo que el negocio está funcionando esa misma mañana, y el trabajo se juzga por si algo se rompió.
Fundó Runink y la dirige como director ejecutivo. Fundador técnico es la mitad más útil de ese título: fija la arquitectura y trabaja en el código, así que quien responde a una pregunta de arquitectura en una primera reunión es quien decidió la respuesta, y la distancia entre una pregunta y un cambio es corta.
Es también la razón por la que la plataforma tiene la forma que tiene. Se ejecuta sobre hardware que controla el cliente, y el razonamiento sobre sus datos se queda ahí. Esa es la manera más cara de construirlo y cierra la vía cómoda, que es el tipo de decisión que tiene que resolver quien es dueño de la arquitectura en lugar de dejarla donde pueda cederse en silencio.
Es Embajador de FINOS. FINOS es la Fintech Open Source Foundation, parte de la Linux Foundation, y el trabajo allí es la interoperabilidad entre instituciones que comparten un mercado pero no su infraestructura y nunca sus datos. Es el mismo problema al que apunta esta plataforma, discutido en abierto, delante de gente que lo dice cuando está mal.
-
Más de 20 años
Transformación digital y modernización a gran escala para grandes empresas.
-
Director ejecutivo y fundador técnico
Runink. Fija la arquitectura y escribe código en ella.
-
Embajador de FINOS
Fintech Open Source Foundation, un proyecto de la Linux Foundation. Interoperabilidad de código abierto, en público.
Compruebe cualquiera de estos datos
Un paso siguiente
Pídanos que le enseñemos cualquier línea de esta página.
Media hora con quien lleve la seguridad o el cumplimiento en su empresa. Elija una sección: abrimos el software en funcionamiento y el registro que lleva, no una diapositiva que hable de ello.
Reserve una consulta