Neody es un marco para usar datos regulados con modelos de lenguaje. Los números de tarjeta, los expedientes de pacientes, la información privilegiada y los datos personales de clientes se protegen campo por campo, antes de que cualquier modelo los vea. El modelo trabaja con sustitutos que conservan el formato; solo las personas y los sistemas que usted aprueba ven los valores reales, y cada acceso queda en el registro que su auditor le pedirá.
Cada afirmación de esta página está respaldada por una prueba que condiciona nuestra compilación. Si alguna vez se desactiva una prueba, la afirmación sale de esta página ese mismo día.
Tarjeta 4111 1111 1111 2847
Tarjetahabiente Maria Lopez
SSN 123-45-6789
estado-de-cuenta.pdf (escaneado)
Borrador: reembolso de $412.60
Tarjeta 4111 11XX XXXX 2847 pv_01HX…
Tarjetahabiente [PII:name#a1]
SSN [PII:ssn#b7]
estado-de-cuenta.pdf → 14 fragmentos protegidos
Borrador: reembolso de $412.60
PCIPII
“Empiece sin PCI con KYC o riesgo de terceros. Agregue datos de tarjetas cuando la zona de protección en sus instalaciones esté activa.”
PHI · HIPAAPII
“Autorización previa y fraude con PHI, aplicando el mínimo necesario por campo.”
MNPIPII
“Una muralla de información que se aplica, no una política, con los límites de detección dichos con claridad.”
PCIPII
“El modelo trabaja con sustitutos del número de tarjeta que siguen validando y coincidiendo, nunca con la tarjeta en sí.”
PIIPCI
“Revise todo el expediente de crédito sin que el modelo sepa nunca quién es el solicitante.”
PIIPCI
“Las identidades y los datos de pago de los jugadores siguen protegidos, caso tras caso.”
Cifrar un documento completo lo vuelve inútil para un modelo; tachar datos elimina lo que el modelo necesita. Neody protege valores individuales y deja legible la estructura.
Cada valor lleva su clase de dato (PCI, PHI, MNPI, PII, secreto comercial) dentro de documentos, correos y llamadas a herramientas, incluidos PDF escaneados, verificado mediante una nueva extracción.
El modelo recibe tokens que conservan el formato y referencias cortas: un número de tarjeta tokenizado sigue validando y cruzando datos, pero no es la tarjeta. El modelo nunca maneja texto cifrado.
Por clase de dato y por agente: claves gestionadas por la plataforma, claves por agente o datos sellados para que ni la propia plataforma pueda leerlos. Escrito en el estatuto del agente y aplicado, no solo configurado.
Nada sin proteger cruza la frontera de salida. Los destinos salen de una lista que aprueba su institución; las claves son por cliente, en poder del cliente y revocables.
Los nuestros, los de sus proveedores o los suyos: autonomía ganada con la coincidencia medida con sus revisores y un registro de evidencia por campo, listo para riesgo de modelos, riesgo de terceros y auditoría.
Los números de tarjeta se protegen en sus instalaciones antes de que algo llegue a Neody.
El objetivo es que Neody quede fuera de su alcance PCI: los datos de tarjetahabientes se sellan para que la plataforma no pueda leerlos, y el modelo solo ve un sustituto que conserva el formato.
Disponible. Decimos “fuera de su alcance PCI” solo con una opinión de alcance de un QSA por escrito; pregúntenos en qué estado está.
Mínimo necesario, aplicado por campo y por agente.
Cada agente ve solo la PHI que su tarea requiere, sobre sustitutos siempre que sea posible; cada acceso queda registrado con su propósito.
Disponible. HIPAA es tanto un contrato como un conjunto de controles; pregúntenos por la preparación y las condiciones del BAA.
Solo los agentes del equipo de la operación la ven.
Acceso limitado a personas y clases de datos nombradas, cruces de muralla y listas restringidas aplicados en tiempo de ejecución, y un registro de quién vio qué y cuándo.
Detectamos MNPI y aplicamos barreras, y decimos los límites con claridad: no existe una suma de verificación para la materialidad.
El modelo razona sobre sustitutos, no sobre sus clientes.
Nombres, números de seguro social, números de cuenta y direcciones se tokenizan de forma consistente, para que el modelo pueda seguir cotejando y comparando registros sin saber de quién son.
Disponible.
Cada afirmación de la izquierda está respaldada por una prueba que condiciona nuestra compilación. Si alguna vez se desactiva esa prueba, la afirmación sale de esta página ese mismo día.
| Decimos | No decimos |
|---|---|
| Los datos regulados se protegen antes de llegar a un modelo público, y nada sin proteger cruza la frontera de salida | “Cifrado de extremo a extremo”: nosotros ejecutamos los agentes y, en algunos niveles, desciframos para procesar |
| Los datos de tarjetahabientes nunca salen sin proteger de sus instalaciones | “Nunca vemos sus datos”: solo es cierto para las clases de datos selladas |
| Claves por cliente, en poder del cliente y revocables | “Sus datos nunca salen de su edificio”: imposible mientras ejecutemos sus agentes |
| Detección de MNPI más aplicación de barreras, con los límites indicados en el producto | Que la MNPI se pueda detectar de forma confiable: la materialidad no tiene suma de verificación |
| Las clases de datos selladas nos impiden leer un valor | Que las claves por agente mantengan los datos confidenciales frente a nosotros: limitan el alcance del daño si una clave se ve comprometida |
Las partes de NeodyAI que permiten a las empresas reguladas usar IA con datos que no pueden enviar a la IA, y que hacen que la autonomía dependa de la evidencia, son objeto de tres solicitudes de patente presentadas en EE. UU.
Mapeamos cada campo (su clase, quién puede leerlo, adónde va) en un Informe de Ruta de Datos antes de ejecutar nada; luego hacemos un piloto en modo sombra junto a sus revisores y medimos con qué frecuencia coinciden.