Gobernanza de Datos para Agentes de IA: Cómo DataSpoc Mantiene Tu Lake Seguro

En el momento en que le das a un agente de IA acceso a tus datos, alguien en seguridad preguntará: “¿Qué impide que borre todo?” Pregunta válida. La mayoría de las integraciónes IA-datos no tienen una buena respuesta. DataSpoc sí.

Este artículo cubre el modelo de seguridad que permite a los agentes de IA consultar tu data lake sin introducir nuevos riesgos.

El Temor

Los equipos dudan en conectar agentes de IA a datos por razones válidas:

1. Acceso de escritura: ¿Qué pasa si el agente ejecuta DROP TABLE o DELETE FROM?
2. Proliferación de credenciales: Otro conjunto de contraseñas de base de datos que gestionar y rotar.
3. Exfiltración de datos: ¿Puede el agente enviar datos a destinos no autorizados?
4. Sin registro de auditoría: ¿Cómo sabes a qué datos accedió el agente?
5. Escalamiento de alcance: El agente puede ver todo, incluyendo datos que no debería.

Estos temores están justificados cuando das a los agentes acceso directo a la base de datos. DataSpoc elimina cada uno.

Capa de Seguridad 1: Solo Lectura por Diseño

El servidor MCP de Lens es de solo lectura. No expone operaciónes de escritura. Punto.

from dataspoc_lens import LensClient

lens = LensClient()

# This works — read query
df = lens.query("SELECT * FROM curated_sales LIMIT 10")

# This is rejected — write query
try:
    lens.query("DROP TABLE curated_sales")
except Exception as e:
    print(e)
    # "Write operations are not permitted. Lens is read-only."

# These are also rejected
lens.query("INSERT INTO curated_sales VALUES (...)")  # rejected
lens.query("UPDATE curated_sales SET amount = 0")     # rejected
lens.query("DELETE FROM curated_sales")                # rejected
lens.query("CREATE TABLE test (id INT)")               # rejected

Esto se aplica a nivel de motor, no solo a nivel de prompt. Incluso si un LLM genera una consulta de escritura, Lens no la ejecutará. El analizador SQL verifica cada sentencia antes de la ejecución.

Cuando se usa el servidor MCP, la misma protección aplica:

{
  "mcpServers": {
    "dataspoc-lens": {
      "command": "dataspoc-lens",
      "args": ["mcp"]
    }
  }
}

El servidor MCP expone herramientas cómo query, tables, schema y ask. Ninguna acepta operaciónes de escritura. Un agente de IA conectado vía MCP físicamente no puede modificar tus datos.

Capa de Seguridad 2: IAM en la Nube (Sin Credenciales Nuevas)

DataSpoc nunca gestiona credenciales. Usa tu IAM existente en la nube:

AWS

# Lens uses your existing AWS credentials
# Option 1: AWS SSO (recommended)
aws sso login --profile data-team

# Option 2: IAM role (for EC2/ECS/Lambda)
# Automatically uses the instance/task role

# Option 3: Environment variables
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."

La política IAM controla lo que el agente puede ver:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::company-analytics",
        "arn:aws:s3:::company-analytics/*"
      ]
    },
    {
      "Effect": "Deny",
      "Action": ["s3:PutObject", "s3:DeleteObject"],
      "Resource": "*"
    }
  ]
}

Observa: la política IAM deniega explícitamente acceso de escritura a S3. Incluso si Lens tuviera un bug que permitiera SQL de escritura (no lo tiene), la capa de nube bloquearía la escritura.

GCP

# Use application default credentials
gcloud auth application-default login

# Or service account
export GOOGLE_APPLICATION_CREDENTIALS="/path/to/sa-key.json"

# IAM binding — read-only access to the bucket
- members:
    - serviceAccount:dataspoc-reader@project.iam.gserviceaccount.com
  role: roles/storage.objectViewer

Azure

# Use Azure CLI credentials
az login

# Or managed identity (recommended for production)
export AZURE_STORAGE_ACCOUNT="companylake"

{
  "roleDefinitionName": "Storage Blob Data Reader",
  "scope": "/subscriptions/.../resourceGroups/.../providers/Microsoft.Storage/storageAccounts/companylake"
}

El insight clave: DataSpoc agrega cero credenciales nuevas. El agente de IA tiene exactamente el mismo acceso que el humano que lo configuró. Si tu IAM en la nube dice “esta identidad solo puede leer del bucket de analytics,” eso es todo lo que el agente puede hacer.

Capa de Seguridad 3: Control de Acceso a Nivel de Bucket

Diferentes equipos ven diferentes datos al tener acceso a diferentes buckets:

s3://company-finance    → Finance team only
s3://company-hr         → HR team only
s3://company-product    → Product team only
s3://company-analytics  → Everyone (aggregated, non-sensitive)

Configura Lens para apuntar al bucket apropiado:

# Finance team's agent
export DATASPOC_BUCKET="s3://company-finance"
dataspoc-lens mcp  # This agent sees finance data only

# Product team's agent
export DATASPOC_BUCKET="s3://company-product"
dataspoc-lens mcp  # This agent sees product data only

Un agente configurado con s3://company-product literalmente no puede acceder a s3://company-finance. No sabe que ese bucket existe. El aislamiento está a nivel de infraestructura cloud, no de lógica de aplicación.

Capa de Seguridad 4: Registro de Auditoría

Cada consulta ejecutada a través de Lens es SQL. SQL es texto. El texto se puede registrar.

from dataspoc_lens import LensClient

lens = LensClient()

# Every call to query() or ask() produces a SQL statement
# that can be logged, reviewed, and audited

# ask() returns both the answer and the SQL it generated
answer = lens.ask("How many customers do we have?")
# Internally executes: SELECT COUNT(*) FROM curated_customers
# This SQL is logged to .dataspoc/logs/

Lens registra cada consulta en el bucket:

bucket/
  .dataspoc/
    logs/
      lens/
        2026-04-15T14:30:00Z.json
        2026-04-15T14:31:15Z.json

Cada entrada de log contiene:

{
  "timestamp": "2026-04-15T14:30:00Z",
  "query": "SELECT COUNT(*) FROM curated_customers",
  "source": "mcp",
  "tables_accessed": ["curated_customers"],
  "rows_returned": 1,
  "duration_ms": 45,
  "status": "success"
}

Puedes revisar exactamente a qué datos accedió el agente, cuándo y cuánto. Compara esto con RAG, donde el paso de recuperación es opaco — no puedes ver fácilmente qué fragmentos se enviaron al LLM.

Comparación: Tres Enfoques para el Acceso de IA a Datos

Enfoque 1: Acceso Directo a Base de Datos (Peligroso)

# The agent gets a database connection string
import psycopg2
conn = psycopg2.connect("postgresql://admin:password@prod-db:5432/main")
cursor = conn.cursor()

# Nothing stops the agent from running:
cursor.execute("DROP TABLE customers")  # disaster
cursor.execute("SELECT * FROM hr.salaries")  # data leak
cursor.execute("UPDATE orders SET status = 'shipped'")  # data corruption

Problemas:

• Credenciales en el código
• Acceso completo de lectura/escritura
• Sin limitación de alcance
• Un error destruye datos de producción

Enfoque 2: RAG con Vector Store (No Auditable)

# The agent retrieves chunks from a vector store
results = vector_store.similarity_search("customer salary data", k=20)
# Which 20 chunks were returned? Hard to audit.
# Did they include sensitive HR data? Maybe.
# Can you prove what the LLM saw? Not easily.

Problemas:

• Recuperación opaca (¿qué fragmentos se devolvieron realmente?)
• Los embeddings pueden codificar datos sensibles
• Sin control de acceso a nivel de fila
• No se puede demostrar cumplimiento

Enfoque 3: DataSpoc Lens (Gobernado)

from dataspoc_lens import LensClient

lens = LensClient()  # uses cloud IAM, read-only, scoped to one bucket

# Every action is SQL — auditable, reviewable, explainable
df = lens.query("SELECT region, COUNT(*) FROM curated_sales GROUP BY region")

# Write operations are rejected at engine level
# Access scope is determined by cloud IAM
# Every query is logged with timestamp and tables accessed

Ventajas:

• Sin credenciales que gestionar
• Solo lectura por diseño
• Alcance definido por IAM en la nube
• Registro de auditoría completo
• Cada respuesta se traza a una consulta SQL

Lista de Verificación de Configuración para Producción

Aquí hay una lista paso a paso para desplegar DataSpoc con agentes de IA en un entorno gobernado:

1. Crear una Identidad IAM Dedicada

# AWS: Create a role for the agent
aws iam create-role --role-name dataspoc-agent-reader \
  --assume-role-policy-document file://trust-policy.json

aws iam attach-role-policy --role-name dataspoc-agent-reader \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

2. Restringir a Buckets Específicos

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::company-analytics",
        "arn:aws:s3:::company-analytics/*"
      ]
    }
  ]
}

3. Configurar el Servidor MCP

{
  "mcpServers": {
    "dataspoc-lens": {
      "command": "dataspoc-lens",
      "args": ["mcp"],
      "env": {
        "DATASPOC_BUCKET": "s3://company-analytics",
        "AWS_PROFILE": "dataspoc-agent-reader"
      }
    }
  }
}

4. Habilitar Registro de Consultas

# dataspoc config
logging:
  enabled: true
  destination: "s3://company-analytics/.dataspoc/logs/lens/"
  level: "all"  # logs every query

5. Revisar Logs Regularmente

from dataspoc_lens import LensClient

lens = LensClient()

# Query the agent's own audit logs
df = lens.query("""
    SELECT timestamp, query, tables_accessed, rows_returned
    FROM lens_audit_log
    WHERE timestamp >= CURRENT_DATE - INTERVAL '7 days'
    ORDER BY timestamp DESC
""")
print(df)

La Conclusión

Dar a los agentes de IA acceso a datos no tiene que ser aterrador. El modelo de seguridad de DataSpoc es simple:

1. Motor de solo lectura — las escrituras son imposibles a nivel del analizador SQL
2. IAM en la nube — sin credenciales nuevas, mismos permisos que los humanos
3. Aislamiento por bucket — cada equipo/agente ve solo sus datos
4. Registro de auditoría SQL — cada consulta se registra y es revisable

El resultado: tu equipo de seguridad obtiene la gobernanza que necesita, y tu equipo de datos obtiene agentes de IA que realmente funciónan. Sin compromiso necesario.