AskSam es un asistente del portfolio que responde preguntas sobre el trabajo publicado de Samuel, cita sus fuentes y se detiene cuando se agota la evidencia. Funciona como un servicio independiente de IA fundamentada detrás de una fachada en el mismo origen.
IA aplicada, Sistemas de recuperación, Arquitectura de API, Seguridad, Privacidad, AI FinOps
Demo del producto · 0:18 · Recorrido sin sonido
La fundamentación y sus límites, en la práctica
AskSam pasa de preguntas sobre proyectos y liderazgo a respuestas con citas, y después rechaza una pregunta privada cuando se agota la evidencia publicada.
Pantallas del producto
Abre una pantalla para examinar el recorrido.
01 · Contexto
Qué lo motivó
Un asistente de portfolio hace una promesa acotada: responder a partir de evidencia pública revisada, citarla y reconocer cuándo no es suficiente. El riesgo operativo es más amplio. Preguntas no fiables, ofertas de empleo pegadas, texto recuperado, salidas del modelo, tráfico automatizado, gasto de proveedor y credenciales de servicio atraviesan límites de confianza distintos.
La primera implementación vivía dentro de Under the Hood. Extraerla añadió un segundo reto: transferir la propiedad del runtime sin cambiar el contrato del navegador, copiar el corpus, crear un segundo historial de migraciones ni dejar dos implementaciones mutables del backend.
02 · Enfoque
Cómo funciona
Mantener el navegador en POST /api/ask, dentro del mismo origen. Una fachada de servidor se autentica ante AskSam, reenvía cada solicitud una sola vez y envía únicamente un bucket de admisión derivado mediante HMAC, nunca la IP del cliente sin tratar.
Ejecutar detrás de ese límite el pipeline de evidencia existente: embedding de la consulta, recuperación híbrida acotada al corpus activo y revisado, generación fundamentada, inspección de seguridad de la salida y proyección de citas limitada a campos públicos de Under the Hood.
Tratar la confianza de cada entrega y el gasto de proveedor como un mismo problema operativo. Las pruebas offline no usan proveedor; un perfil smoke de siete casos cubre comportamientos representativos; la evidencia satisfactoria se cachea según código, batería, adaptadores de modelo, dependencias e identidad del corpus; y el benchmark completo en vivo se reserva para cambios relevantes de una entrega.
03 · Decisiones
Lo que elegí por el camino
01
Entregada
Preservar el contrato del navegador mediante una fachada de servidor
Restricción
Una migración directa y cross-origin del navegador habría expuesto un nuevo límite de red y convertido las credenciales del servicio en parte del contrato cliente.
Alternativas consideradas
Mover el navegador directamente a AskSam o mantener dos contratos públicos de solicitud.
Decisión
Mantener POST /api/ask en el mismo origen y reenviar cada solicitud una sola vez a AskSam, sin reintento ni fallback local.
Efecto
La interfaz y el contrato público de respuesta permanecen estables, mientras la propiedad y el despliegue del backend siguen siendo independientes.
02
Entregada
Transferir la propiedad sin duplicar infraestructura
Restricción
Copiar la base de datos, el corpus, el proyecto del proveedor o el registro de migraciones habría creado fuentes de verdad enfrentadas y un trabajo de sincronización arriesgado.
Alternativas consideradas
Provisionar un stack nuevo para AskSam o reingerir el corpus en una infraestructura paralela.
Decisión
Reutilizar sin cambios los recursos existentes de Supabase y GCP, y convertir AskSam en el único propietario del backend y del plano de control.
Efecto
AskSam consume la misma evidencia activa y los mismos recursos de proveedor sin migración de datos, duplicación del corpus ni un segundo registro de escritura.
03
Entregada
Convertir seguridad, rollback y gasto en controles ejecutables
Restricción
Una respuesta fluida no demuestra fundamentación, privacidad, seguridad de políticas de empleo, enrutamiento a un único destino ni coste acotado de proveedor.
Alternativas consideradas
Depender de comprobaciones manuales puntuales o ejecutar el benchmark de pago completo en cada despliegue.
Decisión
Combinar rechazo determinista antes de usar capacidades de pago, controles estrictos de Turnstile y admisión, registros solo agregados, CI sin proveedor, evidencia smoke cacheada, evaluación completa solo para entregas y mecanismos de rollback y kill switch en AskSam.
Efecto
El sistema puede rechazar trabajo inseguro antes de usar capacidades de pago, evitar repetir gasto de benchmark y recuperarse sin operaciones sobre la base de datos ni el corpus.
04 · Estado actual
Qué es cierto hoy
Entregado
AskSam es el único propietario del backend y recibe todas las solicitudes de la fachada sin cambios de Under the Hood, que no dispone de reintento ni fallback local.
Evidencia
Las pruebas de contrato demuestran un único destino; una sonda de producción sin proveedor registró una invocación de Under the Hood y otra de AskSam, ambas con el rechazo esperado de Turnstile; los dos repositorios superan CI y no se ha copiado ni renombrado ningún recurso de Supabase, GCP, corpus, migración o DNS.
Pendiente
La evidencia prevista para siete días y para todas las clases de estado de Gate 5 no existe porque el operador aceptó ese riesgo para cerrar la propiedad de inmediato. Los medios revisados cubren ahora entrada, cita fundamentada y ausencia explícita de respuesta, en lugar del plan original de cinco estados. La interfaz independiente de sampadilla.com pertenece a Phase 7.
Una extracción segura de IA consiste menos en mover código que en preservar una única fuente de verdad y hacer observables los límites de confianza, gasto y rollback.
Una fachada puede separar la propiedad del runtime de la continuidad del producto
Evidencia
El contrato del navegador y la interfaz no cambiaron mientras el backend se trasladó a un servicio desplegado por separado con exactamente un destino de solicitud.
La próxima vez
Definir el contrato público estable y el dispatcher de destino único antes de crear el despliegue del nuevo servicio.
Los controles desactivados por defecto deben probarse en la configuración desplegada
Evidencia
La primera sonda de enrutamiento completo detectó que Turnstile no se aplicaba, provocó un rollback inmediato y solo pasó después de volver a desplegar el servicio con verificación estricta.
La próxima vez
Sondear cada control de producción desactivado por defecto en el límite previo al proveedor más barato antes de permitir más tráfico.
La frecuencia de evaluación es una decisión de arquitectura
Evidencia
CI sin proveedor, cobertura smoke representativa, evidencia PASS direccionada por contenido y evaluación completa solo para entregas separan la confianza rutinaria del benchmark de pago.
La próxima vez
Diseñar la reutilización de evidencias y los presupuestos estrictos de proveedor junto con el evaluador, no después de que crezca el uso.