01Portafolio
ConstruidoLa demo y sus artefactos se reproducen sin hardware: mismos seed y reloj, mismo resultado. No se publicó ni desplegó todavía.
- Demo local reproducible
- Artefactos (result/manifest)
- Vídeo de 90 s: futuro
Conciencia AI Labs · laboratorio de ingeniería e investigación
Operaciones de IA,
gobernadas y verificables.
Investigamos cómo gobernar y verificar operaciones de IA de punta a punta, empezando en pequeño: agentes que ejecutan, gates que autorizan, evidencia que prueba. Construimos el andamiaje de gobierno sobre el Conciencia AI Control Plane y lo ponemos a prueba en el Lab sobre infraestructura real, sin prometer más de lo que demuestra.
EXP-003: H200 real · inferencia verificadaVM detenida · evidencia sanitizada
El Laboratorio investiga operaciones gobernadas. El producto del ecosistema es el Control Plane; la web institucional vive en conciencia.software.
eco.map · sim
- agentes
- modelos
- APIs
- infraestructura
- evidencia
Recorrido
El ecosistema, capa por capa
Al avanzar, el grafo se transforma y conecta agentes, modelos, APIs, infraestructura y evidencia. Cada bloque declara su madurez real.
eco.map · sim
Agentes conectados a modelos, sin acoplarse a un proveedor.
Capacidades existentes
ConstruidoLo que ya existe: un plano de control para agentes
Conciencia AI Control Plane orquesta agentes de cualquier runtime, exige aprobación humana en acciones sensibles y deja evidencia trazable de cada step. Es el sustrato sobre el que el Lab investiga operaciones gobernadas.
- Missionsorquestación
- Unidades de trabajo con alcance, estado y trazabilidad de punta a punta.
- Workflowsorquestación
- Secuencias de steps ejecutables, con pausas y reanudación.
- Agentsorquestación
- Ejecutores de cualquier runtime, con límites de autonomía por agente.
- Teamsorquestación
- Agrupación y coordinación de agentes por función.
- Harnessorquestación
- Andamiaje de ejecución: contratos, herramientas y contexto del agente.
- Contextoperación
- Context packs acotados: viaja solo el contexto que la misión necesita.
- Signalsevidencia
- Eventos de ingesta que conectan el mundo real con la misión.
- Evidenceevidencia
- Evidencia vinculada a cada step, auditable después del hecho.
- Approvalsgobierno
- Gate humano antes de acciones sensibles (human-in-the-loop).
- Observabilityevidencia
- Timeline del run: qué pasó, quién lo aprobó, con qué respaldo.
- CLIoperación
- Operación del plano de control desde la terminal.
- MCP / WebMCPoperación
- Interfaz de herramientas para agentes vía Model Context Protocol.
El Control Plane es un producto real y desplegado. El Lab no inventa sus capacidades: las usa como sustrato y las somete a prueba. Ver el Control Plane →
Experimentos
Status: PASSExperimental
EXP-001 — Controlled Cloud Reliability Loop
Un experimento pequeño y real sobre una VM Linux: un workload FastAPI aislado (systemd, solo loopback) se somete a un fallo de servicio controlado. Validamos detección, evidencia, diagnóstico, aprobación humana, remediación y verificación.
- Environment
- Linux Cloud VM
- Scenario
- Controlled service failure
- Version
- v0.2
Fallo intencional · entorno real, sin GPU
- 01DETECTED
Detección
El workload deja de responder: health sin respuesta, unit inactive/dead y sin listener en el puerto dedicado.
- 02EVIDENCE
Evidencia
Evidencia estructurada (JSONL) con observación, inferencia, decisión humana y acción separadas.
- 03DIAGNOSIS
Diagnóstico
El diagnóstico se deriva de la evidencia: causa raíz SERVICE_STOPPED (parada intencional, no crash).
- 04APPROVAL
Aprobación humana
Dos aprobaciones explícitas del operador: una antes de provocar el fallo y otra antes de remediar.
- 05REMEDIATED
Remediación
Se levanta el servicio (systemctl start). Nada se ejecuta sin la aprobación previa.
- 06VERIFIED
Verificación
Health 200 posterior y comparación BEFORE / INCIDENT / AFTER. La verificación no asume el estado del ejecutor.
Resultados observados — BEFORE / INCIDENT / AFTER
| campo | before | incident | after |
|---|---|---|---|
| service_state | active / running | inactive / dead | active / running |
| http_status | 200 | 0 (refused) | 200 |
| latency_ms | 10–16 | — | 10–13 |
| main_pid | 2447403 | 0 | 2453075 |
What this proves
- Observación de un workload real y detección de su indisponibilidad.
- Captura de evidencia estructurada y diagnóstico basado en evidencia.
- Aprobación humana previa, remediación y verificación posterior.
What this does not prove
- No es infraestructura GPU ni una AI Factory en producción.
- No prueba operación a escala ni recuperación ante fallas espontáneas.
- El incidente fue intencional y controlado (no una falla real imprevista).
- Approval gate genérico para acciones de SO: PARTIAL (no integrado).
Approval integration: PARTIAL — la aprobación humana fue real y quedó registrada, pero el gate genérico para acciones de SO todavía no está integrado.
Evidencia sanitizada y reporte completo en el repositorio del Lab.
Experimentos
Status: OBSERVEDExperimental
EXP-002A — Provider readiness probe
Un probe real contra un endpoint de inferencia GPU-cloud (Crusoe Cloud · GLM-5.3-Flash). Tres corridas documentan el contrato de respuesta y un modo de falla por capacidad. No evalúa calidad, costo ni SLA.
- Provider
- Crusoe Cloud
- Model
- zai-org/GLM-5.3-Flash
- Corridas
- 3
Proveedor real · sin GPU propia · EXP-002A ≠ fixture EXP-002
| # | resultado observado | finish |
|---|---|---|
| 01 | Respuesta sin contenido visible | — |
| 02 | HTTP 503 capacity_unavailable | — |
| 03 | Inferencia exitosa · 2,071 s · 51 tokens | stop |
El proveedor es alcanzable y compatible con el SDK de OpenAI, pero no fue 100% confiable en una sola pasada: una respuesta vacía y un 503 por capacidad. La resiliencia (retry, backoff, fallback) es el foco de EXP-002B, no de este probe.
Evidencia sanitizada en el repositorio del Lab.
Experimentos
Status: Session 001 completedExperimental
EXP-003 — NVIDIA H200 GPU Inference on Nebius AI Cloud
Una H200 real en Nebius, CUDA 13.0, PyTorch, DCGM, Docker y vLLM 0.32.0 sirviendo Qwen3-0.6B. Validamos el camino completo hasta una API compatible con OpenAI y medimos un benchmark HTTP secuencial pequeño.
- Provider
- Nebius AI Cloud
- GPU
- NVIDIA H200 NVLink
- Model
- Qwen/Qwen3-0.6B
- VM
- STOPPED
GPU real · inferencia servida · VM detenida al cierre
Latencia media
207,73 ms
Throughput observado
559,86 tokens/s
Solicitudes
10 secuenciales
Tokens de salida
1.163
Gasto de sesión
~USD 1,70 en ~55 min
Estado de la VM
STOPPED
Cliente HTTPvLLM 0.32.0Qwen3-0.6BNVIDIA H200
El benchmark secuencial dio 207,73 ms de latencia media y 559,86 tokens/s agregados, con 1.163 tokens de salida. No es throughput máximo ni una evaluación de calidad: 4 de 10 respuestas alcanzaron max_tokens=128. La evidencia está sanitizada y los originales permanecen privados.
Cuatro pilares
Un laboratorio abierto: del artefacto al negocio
El Lab organiza su trabajo en cuatro frentes. Ninguno promete más de lo que demuestra hoy.
02Educación
ExperimentalSe practican puertos Python, reloj/seed, unidades, pruebas negativas, contratos HTTP e idempotencia. Linux, redes, CUDA, Kubernetes y DCGM quedan como aprendizaje futuro.
- Pruebas negativas
- Contratos HTTP
- Observación independiente
03Investigación
ExperimentalHipótesis: gates e invariantes reducen ejecuciones no autorizadas en este modelo. Método: misma entrada, tres decisiones, más control con evidencia incompleta y recuperación fallida.
- Hipótesis acotada
- Control adversarial
- Sin comparación LLM/hardware
04Oportunidades
PlaneadoHipótesis de valor en integración y trazabilidad de operaciones. Faltan entrevistas autorizadas, comparación con runbooks/nativas NVIDIA, medición de tiempo humano y disposición a pagar.
- Sin ahorro medido
- Sin presupuesto aplicado
- Hipótesis, no promesa
Evidencia, gobierno y límites
PlaneadoQué falta y qué no se debe inferir
El valor del Lab está en decir con precisión qué demuestra. Estos son los bordes: lo que hoy no existe, lo que es solo un diseño y lo que sigue abierto.
Límites declarados
- GPU real, DCGM, scheduler y energía: no implementados.
- Training, inferencia y compatibilidad NVIDIA: no afirmados.
- Identidad, roles, policy y presupuesto: sin enforcement acreditado.
- Aprobación del core sin binding de hash/target/identidad/expiración.
- Gate genérico de aprobación para acciones de SO: no integrado (EXP-001 → PARTIAL).
- Ahorro, reducción de incidentes y disposición a pagar: no medidos.
Experimentos — real vs. simulado
- EXP-002AProvider readiness probe (Crusoe · GLM-5.3-Flash)REAL
Ejecutado sobre un proveedor real. 3 corridas: vacío, 503, éxito (2.071 s, 51 tokens).
- EXP-002Ingesta y reintentos
Fixture de diseño: fallo tras escritura, acuse idempotente.
SIMULATEDExperimental - EXP-003Evidencia conflictiva
Fixture de diseño: señales que se contradicen.
SIMULATEDExperimental - EXP-004Workloads que no terminan
Fixture de diseño: sin fin de job no hay enfriamiento.
SIMULATEDPlaneado - EXP-005Comparación con runbooks
Fixture de diseño: runbook humano vs. flujo gobernado.
SIMULATEDPlaneado
EXP-002A es REAL (proveedor externo real). EXP-002…005 son SIMULATED: fixtures de diseño, sin hardware ni APIs pagas.
Ver todos los experimentos →eco.map · sim
- agentes
- modelos
- APIs
- infraestructura
- evidencia
capa 1 Agentes conectados a modelos, sin acoplarse a un proveedor.
Próximos pasos
La próxima etapa del Lab
La demo v0.1 sigue corriendo sin hardware. EXP-003 se ejecutó sobre una H200 real y la VM quedó detenida. Lo que sigue es investigación aplicada, con autorización explícita por fase.
- 01Ejecutar EXP-003 Session 002: modelos 8B/14B, concurrencia y TTFT.
- 02Conciliar el costo con Billing y ampliar la observabilidad del Lab.
- 03Implementar EXP-002B y EXP-004…005 sobre el harness existente.
- 04Controlar el binding de aprobación (hash, target, identidad, expiración).
Contacto
Hablemos de operaciones gobernadas
Conciencia AI Labs · Ciudad del Este, Paraguay.