La IA ya está democratizada. Ahora toca operarla y securizarla: guía práctica para un “AI Gateway” privado (tipo PrivateGPT) en tu perímetro

En muchas empresas la IA generativa ya no es un piloto: es una herramienta cotidiana. El siguiente salto no es “usar más IA”, sino operarla con disciplina y acercarla al dato. Eso implica llevar parte del cerebro a casa: un AI Gateway privado (al estilo de PrivateGPT), con RAG sobre fuentes internas, auditoría, DLP, SSO/RBAC y sin fuga de prompts ni embeddings a terceros.

Este artículo es una “hoja de ruta” técnico-operativa: arquitectura de referencia, seguridad, sizing, observabilidad, CI/CD de prompts y RAG, y un plan de 12 semanas para pasar de SaaS improvisado a infra de IA gobernada.

---

¿Por qué un gateway privado?

• Cumplimiento y confidencialidad: prompts, adjuntos y resultados que no deben salir del dominio.
• Latencia y continuidad: pegado al dato, sin dependencia de cuellos de egress ni ventanas de proveedor.
• Coste predecible: cargas intensivas con GPUs bare-metal o cloud privado estabilizan el OPEX.
• Gobernanza: logging de quién, qué, cuándo y con qué fuente; políticas de entrada/salida; guardrails.
• Ventaja específica: la diferencia la marca tu corpus y procesos, no el modelo genérico.

---

Arquitectura de referencia (opcionalmente con PrivateGPT como pasarela)

Plano de acceso (Control Plane)

• Gateway HTTP/WS con SSO (OIDC/SAML), RBAC, rate limiting, quotas y políticas de DLP/PII.
• Policy engine (p. ej., OPA/Rego) para decidir routing (modelo local vs externo), qué entra/sale y quién puede ver qué.
• Auditoría: trazas y eventos firmados (ver esquema más abajo).

Plano de datos (Data Plane / RAG)

• Conectores a DMS, wiki, CRM/ERP, tickets, shares; ETL → normalización (PDF→texto, OCR, limpieza) → chunking → embeddings → vector store.
• Vector DB (pgvector/Qdrant/Weaviate/Milvus): namespaces por dominio, TTL por colección, cifrado en reposo.
• DLP/PII scanner en ingestión (señales para guardrails).

Plano de modelos (Model Serving)

• LLM host (vLLM/Ollama u orquestador comercial) para modelos locales (instruct/funciones) y routing a externos cuando proceda.
• Embeddings service dedicado para throughput y caching.
• Content filters de salida (PII/secretos, toxicity, jailbreak).

Red y seguridad

• TLS externo; mTLS interno entre gateway ↔ RAG ↔ modelos ↔ vector DB.
• KMS/HSM para claves de cifrado, envelope encryption de registros sensibles.
• Zonas: DMZ (gateway), app-net (servicios), data-net (DBs).
• Egress control: lista blanca de destinos externos; sin ruta por defecto a internet desde pods de RAG.

---

Diseño de RAG que no se arrastra

1) Chunking y metadata

• General: chunk_size 800–1200 tokens, overlap 100–200.
• Documentos largos (contratos/manuales): sub-chunking semántico (títulos, secciones).
• Metadata obligatoria: origen, versión, doc_id, section, acl tags, idioma, timestamp, hash de contenido.

2) Embeddings

• Dimensiones 384–1024 según modelo; normaliza y cachea (Redis/LFU).
• Regla práctica: 1M chunks ≈ 1–2 GB embeddings (dim=384) / 4–8 GB (dim=1024).
• Evita recalcular embeddings por cada cambio menor; usa versionado de corpus.

3) Búsqueda

• Híbrida (BM25 + vector), k = 20, re-ranker ligero → 6–10 pasajes al prompt.
• ACL-aware retrieval: filtra por acl tags antes de la búsqueda (no confíes sólo en el LLM).

4) Prompting

• Templates versionados; inserta fuentes con URL interna/verificable; fomenta respuestas con citas.
• Stop sequences y max tokens por dominio.

---

Sizing y rendimiento: reglas rápidas

Latencia objetivo (95p)

• Política “rápido y útil”: embedding search ≤ 80 ms, re-rank ≤ 70 ms, first token ≤ 400 ms.
• TTFT (time-to-first-token) sube con modelos grandes; mix de modelos: instruct pequeño (respuesta rápida) + fallback a mayor.

Memoria VRAM (estimación gruesa)

• FP16: ≈ 2 × params (GB); INT8: ≈ 1 × params; INT4: ≈ 0,6 × params.
• Un 7B INT4 cabe en ~4–5 GB; 13B INT4 en ~8–10 GB; 70B exige varias GPUs o CPU+disco (lento).
• Concurrencia ≈ min(threads_serving, VRAM / working set por petición).

Vector DB

• 1M vectores (dim=768) ≈ 3–5 GB; añade 30–50 % por índices y metadatos.
• IOPS manda: NVMe local o pool flash para colecciones activas.

Coste

• Calcula €/k tokens internos vs externos; añade egress. En cargas masivas, el break-even de servir local llega rápido.

---

Seguridad y cumplimiento (para pasar auditorías sin sudar)

• PII/Secrets “shift-left”: escaneo en ingestión y en respuesta, con masking y policy deny.
• Retención: TTL para prompts, eventos y cache; borrado verificado (hash después del delete).
• Consent & purpose: etiqueta conjuntos con el propósito (contabilidad, soporte, legal); evita reuso cruzado.
• Identidad: SSO con claims: dept, role, region. Las ACL del RAG consumen esos claims.
• Trazabilidad: cada respuesta guarda req_id, user, sources[], model, hash_input/output, policy_decisions.
• Backups/DR: el vector DB se respalda (snapshots + logs de WAL/raft); runbook para reconstruir índices desde fuentes si es necesario (y comprobar hashes).

---

Observabilidad y auditoría

• Métricas: QPS, TTFT, tokens/s, caché hit-ratio, latencias (p50/p95/p99), errores de retrieval, timeouts.
• Trazas (OpenTelemetry): span para gateway → RAG → search → re-rank → LLM.
• Logs: schema estable (JSON) y signatura de eventos críticos; PII minimization (hash/salt).
• Paneles: latencia por route, drift en embeddings (colapsos de calidad), coste por caso de uso.

---

DevOps de IA: CI/CD de prompts y RAG

• Prompts como código: repos, branching, review, canaries y rollbacks.
• Golden sets: fixtures de preguntas/respuestas esperadas por dominio (legal, compras, soporte).
• Evaluación: automatiza faithfulness, groundedness, toxicity, jailbreak y exactitud factual en QA.
• Red-teaming: prompt injection, data exfil, role overwrite, tool abuse; bloquea y notifica.

---

Ejemplo (orientativo) de docker-compose para un stack mínimo

services:
  gateway:
    image: yourorg/ai-gateway:latest
    env_file: gateway.env
    ports: ["443:8443"]
    depends_on: [retriever, vllm]
    # TLS y mTLS internos; OIDC para SSO
  retriever:
    image: yourorg/rag-service:latest
    environment:
      VECTOR_URL: http://qdrant:6333
      EMBED_URL: http://embed:8080
    depends_on: [qdrant, embed]
  embed:
    image: yourorg/embeddings:latest
    environment:
      MODEL: "bge-base-en-v1.5"
      CACHE_URL: "redis://cache:6379/0"
  vllm:
    image: vllm/vllm-openai:latest
    environment:
      MODEL: "llama-3-8b-instruct-q4"
      VLLM_WORKERS: "2"
    deploy:
      resources:
        reservations:
          devices:
            - capabilities: [gpu]
  qdrant:
    image: qdrant/qdrant:latest
    volumes: ["./qdrant:/qdrant/storage"]
  cache:
    image: redis:7-alpine
Lenguaje del código: PHP (php)

Sustituye imágenes por las de tu proveedor/stack. En producción: TLS, mTLS, health checks, límites de recursos, node affinity, backups y secrets fuera del compose.

---

Plan de 12 semanas

Semanas 1–2 — Descubrimiento y control de riesgos

• Inventario de casos de uso y datos sensibles.
• Quick wins que no requieren datos regulados (resúmenes, playbooks internos).

Semanas 3–5 — MVP del gateway

• Despliega gateway con SSO/RBAC, mTLS y auditoría.
• RAG mínimo: conectores a shares/wiki, vector DB, embeddings, templates básicos.
• DLP/PII de entrada y salida.

Semanas 6–8 — Calibración y SLAs

• Define SLOs (p95 TTFT, p95 end-to-end, disponibilidad).
• Load tests: QPS objetivo, concurrencia, saturación de VRAM y vector DB.
• Ajusta chunking, re-rank y guardrails.

Semanas 9–10 — CI/CD y seguridad

• Prompts como código, golden sets, evaluación automática.
• Red-team de prompt injection y exfil.
• Backups, DR y runbooks.

Semanas 11–12 — Industrialización

• Abrir a más áreas con playbooks por rol.
• Costeo: €/k tokens internos vs externos; enrutado según caso.
• Revisión con Legal/Compliance y hardening final.

---

Anti-patrones que verás (y cómo evitarlos)

• “Todos a SaaS” con datos sensibles → patrón bimodal; lo crítico, por tu gateway.
• RAG sin ACLs → filtra por claims/ACL tags antes de buscar.
• Embeddings recalcados por cada cambio menor → versión y cache.
• Logs detallistas con PII → minimize & hash + retención corta.
• Sin golden sets ni CI/CD de prompts → regresiones silenciosas y “magia” en producción.

---

Conclusión

Ya democratizamos la IA: ahora toca operarla como una plataforma crítica. Un AI Gateway privado —al estilo PrivateGPT— aporta la mezcla que un admin aprecia: seguridad, control, rendimiento y trazabilidad. El modelo bimodal (SaaS cuando conviene, privado cuando duele) equilibra productividad con soberanía del dato. Métricas, SLOs, guardrails y CI/CD harán el resto.

Checklist final: SSO/RBAC ✅ mTLS/TLS ✅ DLP/PII ✅ RAG con ACLs ✅ Auditoría firmada ✅ SLOs/observabilidad ✅ CI/CD de prompts ✅ Red-teaming ✅ Backups/DR ✅

Con eso en su sitio, la IA deja de ser un experimento y se convierte en infraestructura operable. Y, como cualquier otra, se gana manteniéndola bajo tu control.

vía: Informe wharton y noticias inteligencia artificial