Cómo trabajo

1. Entender el proceso y el resultado que buscas. Hablo con tu equipo y veo cómo se hace de verdad el trabajo: tus herramientas, tus datos, las excepciones que nadie escribió.

2. Elegir la tarea adecuada. Mapeo tus sistemas y flujos y elijo la tarea que merece pasar a la IA. El mismo mapa enseña dónde está el riesgo frente al AI Act, el RGPD y la seguridad.

3. Definir el alcance y los criterios de aceptación. Dejamos por escrito qué se construye y qué cuenta como hecho.

4. Construir e integrar. Construyo con tus datos reales lo que pida la tarea: un agente de IA, una automatización o software. Se conecta con las herramientas que tu equipo ya usa.

5. Validar contigo. Antes de que el sistema funcione solo, comprobamos juntos que cumple lo acordado.

6. Mantener y medir. La construcción tiene fecha de fin. Después lo mantengo, con el alcance que pida cada proyecto, y cada mes recibes un informe de resultados y coste.

Hasta ahora, comprar software era comprar una herramienta. Alguien de tu equipo tenía que aprender a usarla, alimentarla y revisar lo que decía. Si nadie lo hacía, la herramienta se quedaba sin usar.

Ahora la IA puede hacer ese trabajo de principio a fin: cualificar los contactos que entran, redactar el informe o revisar el expediente. Así lo entrego: tú recibes el trabajo hecho.

A este modelo se le llama Service-as-Software. Lo bautizó Foundation Capital en 2024. En marzo de 2026, Julien Bek, socio de Sequoia, lo llevó más lejos en «Services: The New Software».

Sequoia lo dijo en una línea: «Un copiloto vende la herramienta. Un autopiloto vende el trabajo».

Un sistema de IA que funciona en una demo no sirve de nada si no entiende cómo trabaja tu empresa.

Por eso no trabajo desde fuera. Trabajo como un forward deployed engineer: con tu equipo, entiendo cómo se hace de verdad el trabajo y construyo la solución dentro de tus sistemas, hasta que funciona.

El término nació en Palantir: ingenieros que trabajan dentro de un solo cliente, construyen lo que ese cliente necesita y se miden por su resultado.

Así trabajo también dentro de Sesame HR, donde cada equipo es un cliente interno.

Antes de construir dejamos por escrito qué cuenta como hecho y cómo se comprueba. Por ejemplo, qué datos debe tener un contacto para contar como lead cualificado, o qué preguntas debe responder un informe.

Con ese criterio validamos el sistema contigo antes de que funcione solo. Y con el mismo criterio se mide cada mes.

Cada propuesta separa tres cosas.

Los honorarios: la construcción y la integración en tus sistemas.

Los costes de terceros: los modelos de IA y las herramientas que usa el sistema. La IA no sale gratis, y estos costes los ves en el informe mensual.

El mantenimiento, con el alcance que pida el proyecto.

Los precios y las condiciones se fijan por escrito en cada propuesta, antes de empezar.

La seguridad va primero: claves fuera del código, permisos justos y nada de fuera se trata como una orden. Lo que llega de un correo o de una web es información, no instrucciones.

El RGPD y el AI Act entran en el diseño desde el principio: qué datos se usan y por dónde viajan.

Pruebas automáticas y límites de uso. Cada cambio pasa controles antes de publicarse.

Todo queda registrado: qué hace cada agente, por qué y cuánto cuesta. Cada pieza queda documentada, probada y conectada con las demás. Lo que ya no sirve se retira.

Tareas repetitivas cuyo resultado se puede comprobar: cualificar los contactos que entran, redactar el informe o revisar el expediente.

Trabajo que la empresa ya paga a otros o que hace su equipo. Hay una idea clara de qué es un trabajo bien hecho.

Poca responsabilidad legal. Donde la ley pide la firma de un profesional, firma una persona.

No todo necesita un agente. A veces basta una automatización o software. Otras, una norma y una persona responsable.