Especialista en IA y automatización.

Trabajo con publicidad y negocios online desde 2012. Esa trayectoria me enseñó a empezar por los procesos y los datos. Antes de elegir una herramienta, quiero entender cómo funciona el trabajo, dónde aparecen los errores y qué decisiones necesitan interpretación.

En SpartAds, el equipo ofrece servicios de IA y automatización para negocios que necesitan resolver flujos de trabajo concretos. En Laboratório da IA, reúno a empresarios en dos mentorías al mes sobre negocios online, donde reviso proyectos y comparto los detalles técnicos de lo que construimos.

El trabajo práctico combina código, arquitectura y decisiones de negocio. Para evaluar una herramienta, necesito entender qué recibe, qué puede hacer y cómo vamos a comprobar el resultado. Los ejemplos que desarrollo aquí recorren esas preguntas, desde un proceso de campañas hasta una aplicación que otras personas van a utilizar.

Lo que ya defendía sobre la IA en 2022

En mi libro Aprende a vender com Marketing Digital, escrito en 2022, dediqué dos secciones a los algoritmos y la inteligencia artificial. Hablaba principalmente de la automatización en los anuncios y de la necesidad de desarrollar el pensamiento estratégico. Hoy aplico ese mismo criterio a los modelos de lenguaje y a las herramientas que construyo para mis negocios.

La pregunta ya aparecía en el libro: ¿amenazan los algoritmos el trabajo del gestor de tráfico? Mi preocupación era entender qué haríamos con el tiempo que liberara la máquina. Había más espacio para estudiar la oferta, interpretar resultados y mejorar la conversión. Seguir ocupado ajustando campañas manualmente tenía poco interés si esa intervención no mejoraba el resultado.

Desde entonces, el trabajo que puedo apoyar con IA se ha ampliado. En las clases muestro análisis de archivos, construcción de aplicaciones e integración de herramientas. Son aplicaciones posteriores al libro, con sus propias responsabilidades: decidir qué información se puede usar, qué acciones están autorizadas y cómo confirmar lo que hizo el sistema. La experiencia con anuncios me ayuda a hacer mejores preguntas; aun así, cada aplicación necesita pruebas.

Me gusta empezar con una pregunta sencilla: si esta tarea lleva menos tiempo, ¿en qué voy a emplear ese tiempo? Puede servir para atender mejor a los clientes, revisar proyectos o reducir la sobrecarga del equipo. Después compruebo si eso ha ocurrido. El valor del cambio se manifiesta en el trabajo que podemos entregar y en la calidad con la que lo hacemos.

Cómo describir un proceso antes de automatizarlo

Un proceso solo debería automatizarse cuando puedes describir cada etapa manual sin ambigüedades, identificar las fuentes de datos y definir las reglas para las excepciones. Si el equipo duda sobre quién valida un registro o dónde se guarda el resultado, la automatización solo acelera los errores que ya existen.

Antes de abrir la herramienta, habla con quien realiza la tarea. Pídele que te muestre un caso de principio a fin: qué recibe, qué decide y qué hace cuando falta información. Si cada persona sigue un proceso diferente, acuerda primero cómo debe funcionar el trabajo. Solo después tiene sentido automatizarlo.

Imagina, hipotéticamente, un flujo de captación comercial en el que un formulario introduce una oportunidad en el CRM y notifica a un responsable. La estabilidad depende de las situaciones excepcionales: ¿qué hacer si el contacto ya existe y está asignado a otra persona? ¿Cómo tratar los envíos fuera de horario? Sin esas respuestas definidas por escrito, cualquier automatización generará conflictos de datos.

Para decidir dónde intervenir primero, evalúo cuatro variables: frecuencia de la tarea, tiempo humano empleado, calidad de los datos de origen y costo de un error. Las rutinas frecuentes con entradas estandarizadas ofrecen un retorno más rápido. Las tareas poco frecuentes, con muchas decisiones subjetivas, necesitan primero organización manual, no automatización inmediata.

La guía de automatización de procesos empresariales recorre ese camino hasta la operación diaria. Incluye estados, pruebas de excepciones y responsabilidades de mantenimiento.

Reglas condicionales y modelos de lenguaje: cuándo usar cada enfoque

Las reglas condicionales sirven para cálculos y validaciones lógicas directas; los modelos de lenguaje sirven para interpretar texto no estructurado o extraer información semántica. Confiar la lógica básica del negocio a un modelo probabilístico encarece la operación e introduce fallos difíciles de prever.

En la gestión de las campañas de AdSummit separé la construcción del sistema de su ejecución. Usé IA en la planificación y la escritura del código, pero el motor de ejecución siguió reglas fijas. El sistema lee las métricas cada hora y decide los presupuestos a partir de una matriz predefinida, sin consultar ningún modelo de lenguaje en esa rutina.

Si necesitas comprobar si un costo por adquisición superó un límite, una condición de código permite comprobarlo sin consultar un modelo de lenguaje. Si necesitas clasificar el sentimiento de un mensaje o extraer datos de texto libre, entonces compensa usar un modelo de lenguaje. Mezclar ambas funciones en el mismo bloque de ejecución compromete la fiabilidad del sistema.

Cuando uses un modelo, exige salidas estructuradas, comprueba la integridad de la respuesta y protege el negocio frente a las alucinaciones. Un texto generado por IA nunca debe pasar directamente a una acción crítica de facturación o recorte de presupuesto sin validaciones y permisos específicos para esa acción. En las automatizaciones de seguimiento de campañas, la secuencia es fija: recopilación de datos mediante API, evaluación matemática de límites, ejecución y aviso por WhatsApp. Puedes conocer mejor esta lógica en el artículo cómo usar la IA en el negocio más allá de las preguntas al chatbot.

Cuando el sistema necesita elegir pasos y utilizar herramientas, conviene evaluar los agentes de IA para empresas. Explico cómo definir el alcance, limitar los accesos y comprobar cuándo debe detenerse el agente.

Prospección B2B: recopilar datos, calificar y entregar una oportunidad

La prospección B2B con IA debe recopilar datos de empresas, calificarlas según criterios claros de compatibilidad con la oferta y solo después entregar contactos verificados al equipo comercial. Evita los contactos masivos e indiscriminados: la prioridad es la calidad y el criterio, nunca simplemente el volumen de contactos generado.

Al probar la recopilación y calificación de contactos con Apify, n8n y modelos de lenguaje, encontré resultados muy distintos según la fuente. Intenté extraer contactos de consultas de psicología a través de Instagram y el resultado fue pobre: la mayoría procedía de Brasil, no de Portugal, porque la palabra clave elegida no funcionó bien para ese scraper. En cambio, en Google Maps, el mismo enfoque aplicado a clínicas dentales produjo resultados casi exclusivamente portugueses. Esto ilustra que los resultados dependen mucho de la herramienta y de la palabra clave utilizada, y nada garantiza acertar a la primera.

Cualquier puntuación asignada por IA debe mantener criterios auditables. Si evalúas el sector, el tamaño y la presencia digital, una nota de 1 a 10 sirve para ordenar prioridades, no para predecir la probabilidad de cerrar la venta. Es importante que el equipo comercial sepa distinguir un dato recogido directamente de una inferencia del modelo.

Antes de ampliar la recopilación a grandes volúmenes, conviene comprobar manualmente una muestra: verificar si la actividad de la empresa coincide con el nicho, si los contactos pertenecen a quienes toman decisiones y si los criterios de descarte se aplicaron correctamente. La capacidad de extraer cientos de contactos rápidamente crea la tentación de enviar mensajes genéricos; el trabajo serio va en sentido contrario, afinando los filtros y limitando el volumen a contactos con un encaje real. Profundizo en este proceso en el artículo cómo calificar oportunidades B2B antes de contactar.

Construir software interno: el ejemplo de la aplicación de pronósticos con Claude Code

Construir herramientas internas con vibe coding permite resolver problemas operativos sin depender de plataformas genéricas del mercado, pero el resultado depende de una planificación inicial cuidadosa que defina las reglas, la arquitectura de datos y los accesos antes de escribir código. Sin esa planificación, el riesgo de tener que rehacer trabajo es alto.

Construí con Claude Code una aplicación de pronósticos deportivos para usar con amigos durante el Mundial. El proyecto incluía autenticación, envío de pronósticos bloqueado por horario, puntuación multinivel, actualización automática de partidos mediante una API externa y un área de administración. Empecé a construirla un miércoles al final de la tarde y, a la mañana siguiente, la aplicación ya estaba operativa; después dediqué unas horas más a reforzar la seguridad antes de hacerla pública.

Antes de generar código, escribí cada detalle en un documento: horarios de cierre de los envíos, reglas de puntuación, puntos de consulta de la API deportiva y permisos del panel de administración. En Claude AI, pedí al modelo que me hiciera preguntas exhaustivas sobre los puntos que aún no estaban claros antes de pasar a Claude Code; en ese caso concreto, respondí más de 280 preguntas antes de que el archivo de especificaciones estuviera listo. Ese interrogatorio cerró lagunas que, de otro modo, solo habrían aparecido a mitad de la construcción, obligándome a reescribir partes ya hechas.

Esta disciplina se aplica a portales de clientes, calculadoras de precios o paneles internos. Las instrucciones vagas, como «crea un panel de control comercial», tienden a producir bases de datos desestructuradas y código frágil. Detallar permisos, tipos de usuario y flujos de estado antes de avanzar da al modelo contexto suficiente para construir por fases sin romper lo que ya estaba hecho. Desarrollo este método con más detalle en el artículo cómo planificar una aplicación con Claude Code antes de empezar a programar.

Seguridad antes de publicar un proyecto en internet

Una aplicación construida con apoyo de modelos de lenguaje solo debería exponerse en internet después de una revisión cuidadosa de las credenciales, las reglas de la base de datos y las validaciones del servidor. La rapidez con la que se genera código no sustituye el cuidado técnico necesario para evitar filtraciones de datos.

Dediqué un bloque de trabajo específico a la seguridad después de que la aplicación de pronósticos funcionara. Revisé desde la exclusión de secretos del control de versiones hasta la protección de los datos de los participantes. Que la primera versión permitiera enviar pronósticos no demostraba por sí solo que los accesos estuvieran bien protegidos.

Antes de publicar las herramientas que construyo, sigo unas comprobaciones que considero mínimas:

1. Políticas de acceso en la base de datos. Las tablas con datos privados deben tener reglas de acceso a nivel de fila, con permisos explícitos para los datos de cada usuario.
2. Validación de permisos en el servidor. Ocultar un botón en la interfaz no impide que alguien intente la misma acción por otra vía; el servidor tiene que confirmar la identidad y el permiso en cada solicitud.
3. Aislamiento por identificador. El sistema debe rechazar los intentos de acceder a registros de terceros modificando parámetros de la dirección.
4. Separación de variables de entorno. Las claves de acceso y las credenciales no pueden estar en el repositorio ni aparecer en código expuesto al navegador.
5. Validación de entradas. Los formularios, las cargas de archivos y los parámetros recibidos de API externas necesitan límites y sanitización para evitar inyecciones.

Suelo separar la construcción de la revisión. Para revisar la aplicación que había construido con Claude Code utilicé Codex. El informe me dio puntos que investigar y corregir; después necesité probar los cambios y confirmar el comportamiento de la aplicación.

Para revisar estas capas con ejemplos, consulta las cinco reglas de seguridad de aplicaciones con IA. El recorrido de desarrollo de aplicaciones con IA conecta la revisión con la primera versión, las pruebas y el mantenimiento.

Datos completos y contexto en el análisis de campañas

Para obtener diagnósticos fiables, necesitas proporcionar a la IA datos sin distorsiones y el contexto comercial de tu negocio. Un modelo no adivina las incoherencias de un informe exportado ni evalúa cifras desconectadas de la realidad financiera de la empresa. Sin esa base, el análisis pierde valor y fiabilidad.

Al interpretar un informe publicitario con Claude, encontré un detalle práctico que condicionaba el análisis: el archivo exportado reflejaba únicamente las columnas visibles en la pantalla de la plataforma. Si la exportación omite métricas o incluye totales agregados en la misma tabla, el modelo puede extraer conclusiones erróneas a partir de datos incompletos. Antes de pedir una interpretación, hay que comprobar qué contiene realmente el archivo.

Antes de pedir análisis a un asistente de IA, conviene comprobar si el periodo coincide, si la moneda es la misma, si la nomenclatura de las campañas es coherente y si se han eliminado las filas de totales generales para no duplicar la inversión. También hay que aclarar qué significa cada métrica de conversión: un evento de captación puede ser un lead frío, una llamada telefónica o una compra ya completada.

Después, la pregunta debe reflejar el contexto operativo de la campaña. Evaluar el aumento del costo por clic de una semana a otra es un análisis mecánico; entender si ese aumento es aceptable porque mejoró la conversión comercial exige cruzar datos publicitarios con datos de facturación real. Envía únicamente métricas agregadas y evita transferir nombres, contactos o direcciones de clientes a plataformas públicas de IA.

Desarrollo la preparación de preguntas y la comprobación de cálculos en la guía de análisis de datos con IA para negocios. Es una lectura útil antes de convertir un informe en una decisión sobre campañas o equipos.

Del manual de trabajo del equipo a las instrucciones de una automatización

Un manual de trabajo debe permitir que otra persona ejecute una tarea y entienda las decisiones ya tomadas. En el libro recomendaba documentar objetivos, pasos y aprendizajes para facilitar ese traspaso. Al aplicar hoy esta práctica a la IA, añado los límites de acceso, las situaciones que requieren revisión y la forma de interrumpir una ejecución.

Piensa en una solicitud de presupuesto. El documento puede explicar qué información hace falta, dónde confirmar el servicio solicitado y quién prepara la propuesta. Añade ejemplos de solicitudes completas e incompletas, con el motivo de cada decisión. Si falta información esencial, el proceso debe pedir una aclaración o derivar el caso a una persona responsable.

Entregar ese documento a un modelo ayuda a darle contexto, pero los permisos también tienen que existir en la aplicación. Un asistente que prepara una propuesta no necesita, por ese motivo, poder modificar precios, aprobar descuentos ni enviar la propuesta al cliente. Una instrucción escrita que diga «pedir autorización» necesita una comprobación técnica que impida la acción mientras no exista esa autorización.

El registro de las pruebas también forma parte del manual. Guarda el caso, el resultado esperado, lo que ocurrió y la corrección aplicada, utilizando ejemplos ficticios o debidamente anonimizados. Cuando cambies las instrucciones, una integración o el modelo, vuelve a revisar los casos importantes. Es una aplicación actual de la disciplina de aprendizaje que ya defendía en el libro.

Para profundizar en la parte técnica, conviene distinguir los flujos predefinidos de los agentes y decidir cómo evaluar su comportamiento. En el artículo sobre planificación con Claude Code puedes seguir las decisiones de un proyecto concreto, desde los usuarios y los datos hasta las comprobaciones antes de publicarlo.

Operación diaria: monitorización, fallos y costos

Un sistema automatizado necesita rutinas de monitorización que confirmen la actualización de los datos y eviten acciones destructivas cuando se interrumpen las conexiones de red. Ignorar la gestión de fallos y los límites de consumo convierte un proyecto técnico en un gasto operativo inesperado.

Una automatización fiable distingue la ausencia momentánea de datos de un resultado real de cero. Si una API de pagos no responde durante unos minutos, el sistema debe registrar el incidente y volver a intentarlo de forma controlada, en lugar de asumir que la facturación cayó a cero y lanzar alertas falsas. Las tareas de envío de mensajes o creación de pedidos necesitan claves de idempotencia para que una repetición por un fallo técnico no cree duplicados.

La conexión entre Google Sheets, n8n y las alertas de WhatsApp permite llevar información al equipo cuando necesita actuar. Un aviso útil resume únicamente la anomalía detectada, indica el periodo afectado y enlaza directamente con el registro del error. Los mensajes continuos y genéricos generan fatiga en el equipo y hacen que los incidentes reales pasen desapercibidos.

Conviene seguir el consumo de llamadas a modelos y el costo de computación de cada automatización. Antes de conectar un proceso a miles de registros, probar con una muestra pequeña ayuda a estimar el gasto medio y fijar límites diarios. También compensa medir el tiempo que el equipo sigue dedicando a revisar o corregir los resultados del sistema; esa cuenta ayuda a entender si el proceso realmente mejoró. Puedes ver este equilibrio en el artículo hacer crecer un negocio online: lo que aprendí sobre margen, equipo e IA.

Formación de equipos e integración de IA en el negocio

La adopción de IA en una empresa falla cuando se trata como un ejercicio teórico desconectado de los objetivos de rentabilidad y de las rutinas diarias. La tecnología solo se incorpora de verdad cuando quienes dirigen y quienes ejecutan saben diagnosticar sus propios problemas antes de pedir soluciones a la máquina.

Una empresa puede usar IA a diario y seguir aprovechando solo una parte de sus posibilidades. Redactar textos o resúmenes genéricos resuelve tareas concretas, pero conviene mirar también los costos fijos y los procesos que consumen tiempo. Construir herramientas y automatizaciones exige más preparación; merece evaluarse cuando permite mejorar una dificultad operativa identificada.

Capacitar a los equipos pasa por centrarse primero en los porqués, no en las herramientas. Quien ya conoce la economía del negocio y sabe relacionar métricas financieras multiplica su productividad al recibir herramientas como Claude Code o Codex. Quien no domina los fundamentos del negocio tiende a limitar su uso a pruebas estéticas sin efecto en la facturación. En las inmersiones presenciales que suelo impartir, el formato es el de un taller práctico: cada participante trabaja en un reto real de su empresa y sale con una versión inicial de una herramienta para probar después en su propio negocio.

Cómo trabajar conmigo en esta área

Si necesitas un equipo que implemente, tienes los servicios de SpartAds. Si quieres aprender y hablar de tu proyecto conmigo, conoce Laboratório da IA y las formaciones disponibles. Empieza por explicar qué quieres resolver y qué has intentado ya; eso ayuda a entender cuál de los caminos tiene sentido.

Si buscas un equipo que diseñe e implemente automatizaciones a medida, conoce los servicios de IA y automatización de SpartAds. El equipo evalúa tus flujos existentes y construye integraciones que aporten previsibilidad a la operación.

Si quieres aprender a diseñar estos sistemas y seguir la evolución práctica de estas tecnologías con mi orientación, inscríbete en Laboratório da IA, donde imparto dos mentorías al mes y reviso proyectos prácticos de la comunidad.

Para invitarme a conferencias o formaciones ejecutivas para tu equipo, envía el contexto de tu propuesta a través de la página de invitaciones. Mi equipo evalúa la disponibilidad y aclara los objetivos antes de presentar una propuesta. Para ver cómo conecto este enfoque con la generación de ingresos, continúa en el artículo cómo transformar más leads en clientes en un negocio de servicios.

Una prueba pequeña antes de entregar el proceso al equipo

Antes de entregar una automatización al equipo, prepara una prueba con pocos registros, situaciones diferentes y una persona responsable de la revisión. La prueba debe mostrar qué hace el sistema cuando todo va bien y cuando falta información. Guarda las decisiones para que otra persona pueda entender el resultado y repetir la comprobación.

Imagina una empresa de servicios que recibe solicitudes a través de la web. Este es un ejemplo de diseño de procesos, no un resultado de un cliente: el formulario recoge la solicitud, una regla comprueba los campos necesarios y la IA propone una categoría a partir de la descripción. El equipo confirma la categoría antes de usar esa información para decidir el siguiente contacto.

Prepara tres solicitudes ficticias. En la primera, el servicio está bien identificado; en la segunda, la descripción es vaga; en la tercera, hay dos solicitudes distintas en el mismo mensaje. El sistema debe poder distinguir estos casos y mostrar cuándo no tiene información para continuar. Una respuesta convincente no resuelve una clasificación errónea.

Registra en una hoja sencilla la solicitud, la categoría esperada, la respuesta recibida y el motivo de la diferencia. Si el modelo asigna la misma categoría a todo, revisa el contexto y los ejemplos. Si falta un campo, confirma que la automatización señala esa ausencia en lugar de completarlo con una suposición.

Después prueba el traspaso al equipo. Quien recibe la solicitud debe ver el texto original y poder corregir la clasificación sin depender de quien construyó el flujo. El mensaje interno tiene que indicar el siguiente paso y la persona responsable. La notificación solo ayuda si alguien sabe qué hacer con ella.

También debes ensayar un fallo de la integración. Interrumpe la conexión en un entorno de pruebas y confirma si la solicitud queda guardada, si aparece un aviso y si la recuperación evita duplicar el contacto. No hagas esta prueba con solicitudes reales sin un plan que proteja la operación.

Cuando el proceso esté comprendido, aumenta el volumen por etapas. Controla cuántos casos necesitan corrección, dónde hay retrasos y cuánto cuesta ejecutar el flujo. Esos registros ayudan a decidir si merece la pena continuar, simplificar una etapa o mantener parte del trabajo manual.