Un ex estudiante de Harvard Law levantó 6 millones de dólares para Blue Voice, un asistente de IA para policías que la nota describe como un Harvey para oficiales. El detalle que importa está en una sola línea del anuncio: el sistema se entrena sobre leyes específicas de cada departamento, ordenanzas locales, protocolos y guías internas que las herramientas de propósito general no pueden alcanzar en la internet pública. Podés leer la cobertura original en TechCrunch.
Por qué importa
La señal no es que alguien más haya levantado plata para poner un LLM arriba de un vertical. La señal es dónde quedó ubicado el valor. No está en el modelo: cualquiera alquila el mismo modelo por API. Está en un corpus que no se puede scrapear porque nunca estuvo publicado, y en el proceso de mantenerlo vivo.
Eso invierte la conversación que venimos teniendo hace dos años. Durante un tiempo largo la pregunta de arquitectura fue qué modelo usar y cómo escribir el prompt. Hoy, en cualquier dominio con normativa propia, la pregunta es de dónde sale el documento que respalda la respuesta, quién lo actualiza y cómo se prueba que sigue siendo correcto.
Hay una evidencia lateral muy buena de esta semana. Vercel contó cómo construyó design.md: intentaron portar su skill interna de diseño a un prompt público y falló, porque adentro del repo el agente lee rodeado de componentes reales y ejemplos ya publicados, y afuera solo tiene palabras. Tuvieron que escribir el archivo de cero y validar cada cambio contra siete prompts de evaluación sacados de casos reales. Es exactamente el mismo problema que enfrenta Blue Voice, en otra escala: el contexto no se copia, se destila y se evalúa.
Qué cambia en la práctica
Si trabajás construyendo software para un dominio regulado (salud, legal, seguros, compliance, seguridad pública), el centro de gravedad del proyecto se corre. El pipeline se parece más a esto que a un chat:
┌──────────────┐
│ Normativa │ ordenanzas, protocolos
└──────┬───────┘
│ ingesta + versionado
▼
┌──────────────┐
│ Índice con │ cada fragmento con fecha
│ procedencia │ y jurisdicción
└──────┬───────┘
│ recuperación filtrada
▼
┌──────────────┐
│ Agente + LLM │ responde solo con cita
└──────┬───────┘
│
▼
┌──────────────┐
│ Revisión │ humano responsable
│ humana │
└──────────────┘Las decisiones concretas que aparecen apenas empezás:
- Versionado del corpus, no solo del código. Una ordenanza que cambió en marzo y un índice de enero producen una respuesta correcta según el sistema y equivocada según la realidad. El índice necesita fecha de vigencia por fragmento.
- Procedencia obligatoria. Si el agente no puede citar el documento y la sección, la respuesta no se muestra. Sin cita no hay auditoría posible, y sin auditoría no hay venta a una institución.
- Filtro por jurisdicción antes de la recuperación. El protocolo de un departamento no aplica en el de al lado. Ese filtro es un problema de permisos y de datos, no de prompt.
- Evals propias. El aprendizaje de Vercel aplica igual acá: sin un set repetible de casos reales contra el cual medir cada cambio, estás iterando a ciegas.
- Gobernanza como parte del producto. OpenAI publicó el caso de Gilbert + Tobin, donde la adopción se apoya en compromiso desde la conducción, gobernanza rigurosa y responsabilidad humana explícita. En un vertical regulado eso no es un anexo del contrato: es requisito de compra.
| Dimensión | LLM general | Vertical con corpus propio |
|---|---|---|
| Origen de la respuesta | Web pública y pesos del modelo | Documentación interna con procedencia |
| Actualización | Fuera de tu control | Proceso propio, con costo propio |
| Trazabilidad | Difícil de auditar | Auditable por diseño, si lo diseñás |
| Costo de arranque | Bajo | Alto: ingesta y acuerdos con la institución |
| Riesgo dominante | Alucinación genérica | Respuesta plausible y desactualizada |
Cuándo NO usarlo
Acá va lo incómodo. La nota de TechCrunch no publica ningún dato de precisión, ni benchmarks, ni cómo se mide el error. No hay información sobre tasa de acierto, ni sobre qué pasa cuando el modelo se equivoca frente a un oficial que tiene que decidir en la calle. Con el material disponible no se puede afirmar que funcione bien: se puede afirmar que alguien invirtió en la tesis.
Casos donde yo no metería un sistema así todavía:
- Cuando no hay dueño del corpus. Si nadie dentro de la organización tiene la responsabilidad formal de actualizar los documentos, el producto se degrada solo y nadie se entera hasta el primer incidente.
- Cuando la consecuencia del error no es reversible. Una respuesta equivocada sobre un procedimiento policial no es un bug de UI. Si el flujo no tiene revisión humana obligatoria antes de la acción, el sistema no está listo.
- Cuando el cliente confunde asistente con autoridad. Si en la demo alguien dice que el sistema decide en lugar de sugerir con fuente, el problema es de expectativa y va a explotar en producción.
- Cuando todavía no tenés evals. Sin casos de prueba reales, cada cambio de prompt o de modelo es una apuesta. Conviene esperar y armar el set primero.
- Cuando un buscador sobre los mismos documentos alcanza. Muchas veces el usuario quiere encontrar el párrafo, no una redacción nueva. Buscar bien es más barato y más auditable que generar.
Qué haría hoy
Si mañana me llega un proyecto de este tipo, no arranco por el modelo. Arranco por juntar veinte preguntas reales que hace la gente que va a usar el sistema, con la respuesta correcta y el documento que la respalda. Ese set es la especificación del producto y el criterio de aceptación al mismo tiempo. Después construyo la ingesta con fecha y jurisdicción, y recién ahí elijo modelo, que es la parte más fácil de cambiar y la que menos define el resultado.