De una conexión de solo lectura a un hallazgo que puedes defender

EVIDENT lee tres superficies, y responder solo a la primera es justo como un inventario acaba equivocado. La base de datos guarda dato personal. El código escribe una parte en los logs, donde ningún esquema puede verla. Y una API se lo entrega a otro. Son tres superficies que esta plataforma correlaciona, no una afirmación de que el dato personal solo viva en tres sitios: los almacenes de objetos, las colas, los data lakes, las copias de seguridad y los sistemas de terceros también lo guardan, y quedan fuera de lo que esto lee hoy, no fuera del problema.

EVIDENT lee los tres, los cruza entre sí y conserva el razonamiento.

Qué ocurre, en orden

1. Apuntas EVIDENT a un origen. Una conexión de solo lectura a PostgreSQL, SQL Server, MySQL, MariaDB, Oracle o SQLite, y un repositorio que pueda leer.
2. Lee el catálogo: tablas, columnas, tipos, restricciones, claves foráneas y comentarios. Estructura, no filas: ese es el modo por defecto y el que la mayoría de equipos de seguridad aprueba.
3. Lee el código que mapea contra ese catálogo. Entity Framework, Prisma, TypeORM, Sequelize, SQLAlchemy, Django y JPA se leen como los mapeos que son, así que un campo del código queda emparejado con la columna que hay detrás.
4. Lee lo que expones. Las descripciones OpenAPI y los esquemas GraphQL se revisan con las preguntas que hará quien los audite.
5. Reglas deterministas producen clasificaciones candidatas, cada una con su confianza y su razón declarada.
6. El motor de correlación mira combinaciones y no columnas sueltas, porque una fecha de nacimiento junto a un código postal es un riesgo distinto del de cada una por separado.
7. Lo que las reglas no pueden resolver espera a una persona: en una cola de revisión, y sobre el propio campo allí donde esté dibujado.
8. Una decisión confirmada pasa a formar parte de la evaluación respaldada por evidencia. Una corregida no: nombrar otro elemento queda registrado con quién lo hizo y cuándo, y deja el campo abierto a revisión, porque una corrección que no ha comprobado nadie es una propuesta mejor, no una respuesta. Los informes son vistas de exportación de ese estado, no la fuente de la verdad, y en un análisis posterior las decisiones anteriores y la evidencia que las sostiene siguen ahí: lo que ha cambiado vuelve a revisión.

El proceso, y hacia dónde va

Orígenes -> Conectores -> Evidencia normalizada
                                  |
                       Reglas y correlación
                                  |
              Hallazgos, riesgos y evidencia faltante
                                  |
                Mapeo a marcos + revisión humana
                                  |
                   Remediación -> Verificación
                                  |
                        Historia inmutable

Lo que importa es el PORQUÉ

Cualquier herramienta sabe producir una lista de hallazgos. La pregunta que un revisor hace sobre cada línea de esa lista es cómo lo sabes, y esa es justo la que casi ninguna sabe responder.

Cada hallazgo de EVIDENT nombra la evidencia de la que salió y la versión exacta de la regla que lo produjo. Cuando una conclusión es inferida y no observada, lo dice, declara su confianza y enumera aquello en lo que se apoya. Puedes discrepar de un hallazgo concreto sin tener que desconfiar de todos.

Lo que te dice que no ha podido ver

Todas las herramientas de esta categoría producen hallazgos. Muchas no producen la otra mitad: la lista de lo que nunca llegaron a comprobar.

Un informe que no dice qué no pudo examinar es un informe que quien lo lee supone completo. EVIDENT declara sus límites dentro del documento, con su propio título: si un token se valida de verdad, si la autorización se aplica registro a registro, si existe algún límite de peticiones. Esa es la razón por la que un informe suyo aguanta que lo lea alguien cuyo trabajo es no creérselo.