Perplexity Computer: el agente IA que ejecuta tareas autónomas en tu empresa

Perplexity Computer: un agente IA que trabaja durante horas

Perplexity ha dado un paso audaz con Perplexity Computer, un agente de inteligencia artificial capaz de ejecutar flujos de trabajo complejos de forma autónoma durante horas o incluso días. A diferencia de los chatbots tradicionales que responden pregunta por pregunta, este agente orquesta investigación, codificación, diseño e implementación a través de 20 modelos especializados conectados a más de 400 aplicaciones.

Más allá de la búsqueda: ejecución real de tareas

Perplexity nació como un motor de respuestas, pero Computer lo transforma en un verdadero asistente operativo. Desde un único prompt, el agente puede revisar documentos completos verificando coherencia lógica, integridad estructural y precisión factual. Puede analizar contratos, informes financieros y documentos técnicos sin reescribir desde cero, algo invaluable para equipos comerciales que gestionan múltiples cuentas en un CRM como SuiteCRM.

Comet: el navegador con IA integrada para empresas

Complementando a Computer, Perplexity ha lanzado Comet, un navegador empresarial con IA nativa. Comet Assistant permite investigación en página, resumen de contenidos y tareas autónomas como reservar vuelos, gestionar correos y rellenar formularios. Los administradores empresariales pueden desplegarlo de forma silenciosa en dispositivos macOS y Windows vía MDM.

Memory y MCP: personalización e integración

Dos funcionalidades empresariales clave completan la oferta. Memory permite que Perplexity recuerde hilos previos, preferencias y prioridades para respuestas cada vez más personalizadas. Y el soporte para Model Context Protocol (MCP) permite conectar Perplexity a cualquier herramienta o fuente de datos externa, incluyendo CRMs, bases de datos y herramientas de gestión comercial.

¿Qué significa para equipos técnicos y comerciales?

Perplexity Computer representa una nueva categoría de herramienta: el agente IA que ejecuta trabajo real de forma continua. Para agencias de desarrollo y empresas que gestionan múltiples clientes, la capacidad de delegar investigación de mercado, auditoría de documentos y preparación de propuestas a un agente autónomo libera decenas de horas semanales.

En Keliam exploramos cómo estas herramientas se integran con los ecosistemas de nuestros clientes, conectando agentes IA con plataformas como SuiteCRM y herramientas de prototipado con IA para crear workflows donde la inteligencia artificial no solo asesora, sino que ejecuta.

Actualización — Agosto 2026: qué ha pasado en seis meses

Escribimos las secciones anteriores en febrero de 2026, cuando Computer y Comet eran todavía una promesa para pocos. Medio año después el panorama ha cambiado en dos direcciones opuestas, y las dos importan si estás pensando en meter un agente en tu empresa.

Por un lado, la disponibilidad. Comet dejó de ser un producto restringido: Perplexity lo ha desplegado a escala global y está disponible en iOS, Android, Mac y Windows. En marzo de 2026 llegó la versión empresarial, Comet Enterprise, con lo que las empresas realmente necesitan para plantearse un despliegue serio: distribución vía MDM, control central de políticas y de tratamiento de datos, y —esto es lo relevante— la posibilidad de que el administrador configure exactamente qué acciones puede ejecutar el agente. Perplexity ha desarrollado esa parte de seguridad en colaboración con CrowdStrike.

Por otro lado, los sustos. El mismo marzo de 2026, Zenity Labs publicó PleaseFix, una familia de vulnerabilidades críticas en Comet que permitían secuestrar el agente de forma silenciosa, acceder a ficheros locales y robar credenciales dentro de una sesión ya autenticada. No fue un caso aislado: investigadores de Brave documentaron inyecciones de prompt invisibles a través de capturas de pantalla, y LayerX describió un vector de un solo clic. Una prueba especialmente incómoda consiguió que el navegador cayera en un fraude de phishing en menos de cuatro minutos.

La conclusión no es «no uses agentes». Es que un agente que navega por internet en tu nombre es una superficie de ataque nueva, y que la parte interesante del proyecto no es el modelo: son los permisos. El resto de este artículo va de eso.

Qué es un agente y en qué se diferencia de un chatbot

La palabra «agente» se ha estirado tanto que ya no distingue nada. Una definición operativa que sí sirve: un agente es un sistema que recibe un objetivo, lo descompone en pasos, usa herramientas para actuar sobre sistemas reales y comprueba el resultado antes de darlo por bueno. Un chatbot produce texto; un agente produce cambios de estado —un registro creado, un correo enviado, un fichero modificado—.

Esa diferencia lo cambia todo desde el punto de vista técnico. Un chatbot que se equivoca genera una respuesta mala que alguien descarta. Un agente que se equivoca deja rastro en tus sistemas. Por eso las cuatro piezas del bucle —objetivo, plan, herramientas y verificación— importan menos que la quinta, que casi nunca aparece en las demos: la capa de control. Este mismo marco lo aplicamos, con más ejemplos de negocio, en el artículo sobre agentes de IA en la empresa.

MCP: por qué el estándar importa más que el modelo

El Model Context Protocol que menciona el artículo original ha resultado ser la parte más duradera de todo esto. La razón es sencilla: normaliza cómo un modelo descubre y usa herramientas externas, de modo que la integración deja de escribirse contra un proveedor concreto.

En la práctica eso significa que el trabajo de integración —exponer tu CRM, tu ERP o tu base de datos como un conjunto de operaciones bien definidas— se hace una vez y sobrevive al cambio de modelo. Y el cambio de modelo llega siempre: por precio, por rendimiento o porque el proveedor jubila una versión. Si tu automatización está atada a las peculiaridades de un asistente concreto, cada relevo te cuesta un proyecto entero. Sobre cómo elegir modelo según la tarea, tenemos una comparativa práctica en cómo elegir entre ChatGPT, Claude, Gemini y Perplexity.

La recomendación técnica es la de siempre, aplicada a un contexto nuevo: construye sobre tu API, no sobre la interfaz de nadie. Un servidor MCP montado encima de una API REST bien diseñada es reutilizable, se puede versionar y se puede auditar. Lo contamos aplicado a un caso concreto en el artículo sobre automatizar workflows de SuiteCRM con IA, y la parte de diseño de la API en sí en seguridad de APIs REST.

Permisos: el problema de seguridad que trae un agente

Aquí es donde la mayoría de proyectos se meten en problemas. Un agente útil necesita acceso a sistemas reales, y la tentación es darle las credenciales de un administrador para que «no se quede bloqueado». Es exactamente lo que no hay que hacer.

• Identidad propia. El agente debe tener su propio usuario y sus propias credenciales, nunca las de una persona. Si comparte cuenta con alguien, los registros dejan de servir para nada.
• Mínimo privilegio real. Permisos por operación y por ámbito: leer oportunidades de un pipeline no es lo mismo que borrar cuentas. La pregunta de diseño es qué permisos tendría la persona a la que sustituye en esa tarea concreta, no en su puesto entero.
• Secretos fuera del prompt. Las claves viven en un gestor de secretos, no en la configuración del asistente ni, mucho menos, en el texto de las instrucciones. Es el mismo criterio que aplicamos a las automatizaciones en seguridad en n8n: credenciales y permisos.
• Trazabilidad. Cada acción del agente debería quedar registrada con qué hizo, sobre qué registro y por orden de quién. Sin esto, cuando algo salga raro no habrá forma de reconstruirlo.
• Aprobación humana en lo irreversible. Enviar a un cliente, borrar, pagar, publicar y firmar son acciones que se confirman. El coste de un clic de confirmación es ridículo comparado con el de deshacer.

Que Comet Enterprise permita al administrador decidir qué acciones puede ejecutar el agente va justo en esta dirección, y es la funcionalidad por la que preguntaríamos primero al evaluar cualquier herramienta de esta categoría. Si un producto no te deja acotar lo que hace, no es un producto empresarial todavía.

Inyección de prompt indirecta: el riesgo propio de los agentes que navegan

Este es el riesgo específico —y el mejor documentado— de los agentes que leen páginas web, correos o documentos. El modelo no distingue de forma fiable entre lo que debe hacer y lo que está leyendo. Un atacante incrusta una instrucción hostil en una página, en una invitación de calendario o en un comentario cualquiera, y el modelo la procesa por la misma vía que las órdenes legítimas del usuario.

Los casos publicados en 2026 son ilustrativos: agentes inducidos a tomar el control del gestor de contraseñas del usuario y a cambiar credenciales silenciosamente mientras devolvían respuestas de aspecto inofensivo; inyecciones ocultas dentro de imágenes que el usuario no llega a ver; y ataques de un solo clic. Los fabricantes van parcheando —Perplexity corrigió parte de estos hallazgos—, pero el consenso del sector es incómodo: es un problema difícil de cerrar del todo, porque nace del propio diseño de los modelos de lenguaje.

No se resuelve escribiendo un prompt mejor. Las mitigaciones que funcionan son de arquitectura:

• Tratar todo el contenido externo como datos, nunca como instrucciones, y dejarlo explícito en la configuración del sistema.
• Acotar el alcance: un agente que solo puede leer no puede filtrar nada; uno que puede escribir debería tener un destino de escritura limitado.
• No mezclar en una misma sesión el acceso a información sensible con la navegación por sitios arbitrarios. Perfiles separados, o directamente máquinas separadas.
• Exigir confirmación humana para cualquier acción que envíe datos fuera de la organización.
• Registrar y revisar: la mayoría de estos incidentes se detectan en los logs, no en el momento.

Si tu empresa aún no tiene una base de seguridad sobre la que apoyar esto, el orden razonable de prioridades está en ciberseguridad para empresas: por dónde empezar.

Qué delegar primero (y qué no delegar todavía)

El error clásico al empezar es elegir la tarea más vistosa en lugar de la más rentable. Nosotros ordenamos las candidatas por dos ejes: cuánto se repite y cuánto cuesta un error.

Empieza por lo repetitivo y barato de equivocar: resumir hilos largos, clasificar entradas de soporte, extraer datos de documentos a un formato estructurado, preparar borradores que alguien revisa. Aquí el agente aporta desde el primer día y un fallo se corrige en treinta segundos.

Sigue, con supervisión, por lo repetitivo pero caro de equivocar: preparar propuestas, actualizar registros del CRM, redactar respuestas a cliente. Funciona bien con revisión humana antes del envío, y es donde más horas se recuperan. La integración con el CRM la desarrollamos en IA aplicada a la gestión de clientes.

Descarta lo puntual y barato: si una tarea se hace tres veces al año, montarla cuesta más que hacerla a mano.

Y no delegues todavía lo puntual y caro: pagos, firmas, borrados, decisiones sin vuelta atrás. No porque el agente no sepa, sino porque el coste de un error no lo compensa ningún ahorro de tiempo.

Coste real: dónde se va el dinero

Un agente que trabaja durante horas consume muchísimo más que un chat. La factura no la infla el prompt del usuario, la inflan los pasos intermedios: cada iteración vuelve a leer contexto, vuelve a llamar a herramientas y vuelve a razonar sobre el resultado. Cuatro controles evitan sorpresas:

• Modelo por tarea. Clasificar y extraer no necesita el modelo más caro; razonar sobre un contrato sí. Mezclar modelos según el paso es la optimización de coste más rentable y la que menos se hace.
• Límite de pasos y de tiempo. Todo agente debe tener un tope. Sin él, un bucle mal cerrado se convierte en una factura sorpresa.
• Caché de lo que no cambia. Instrucciones, catálogos y documentos de referencia se reutilizan en vez de reenviarse enteros en cada paso.
• Presupuesto por proyecto y alertas. Igual que con cualquier servicio cloud: un límite de gasto y un aviso al 70%.

La comparación honesta no es «agente contra cero», sino agente contra la alternativa: cuántas horas de persona sustituye y cuánto cuesta la revisión que sigue haciendo falta.

Cómo saber si funciona: cuatro métricas

La mayoría de proyectos de IA no fracasan, simplemente nadie sabe decir si han servido. Con cuatro números basta:

1. Tiempo ahorrado por ciclo, medido antes y después sobre la misma tarea. Sin la medición previa no hay conversación posible.
2. Tasa de intervención humana: qué porcentaje de resultados hay que corregir. Si sube con el tiempo, algo se ha degradado.
3. Tasa de error que llega al cliente. Es la única que justifica frenar el despliegue.
4. Coste por tarea completada, no coste mensual total. Es lo que permite comparar con hacerlo a mano.

Y una regla de gobierno: cada agente en producción necesita un dueño funcional, una persona que responda de lo que hace. Sin dueño, el agente acaba desconectado a los tres meses.

Cumplimiento: RGPD, AI Act y el cuestionario del cliente

Meter un agente en la empresa toca tres frentes normativos a la vez. En materia de protección de datos, lo esencial es saber qué información sale hacia el proveedor, con qué base legal y bajo qué contrato de encargo de tratamiento; conviene comprobar expresamente que los datos no se usan para entrenar modelos. En cuanto al reglamento europeo de IA, sus obligaciones han ido entrando por fases desde 2025 y afectan sobre todo a transparencia y a los usos considerados de alto riesgo; la mayoría de automatizaciones internas de oficina no lo son, pero conviene documentar la evaluación en lugar de suponerla.

Y en el terreno práctico, el que más aprieta: el cuestionario de seguridad de tu cliente. Si tienes un sistema de gestión alineado con ISO 27001, incorporar un agente es un control más: inventario del activo, análisis de riesgo, permisos, registro y revisión periódica. Si no lo tienes, el agente será justo la pregunta que no sabrás responder.

Cinco errores que vemos al implantar agentes

1. Empezar por la demo bonita. El agente que impresiona en la reunión rara vez es el que ahorra horas.
2. Dar permisos de administrador «temporalmente». Nada dura tanto como lo temporal.
3. No medir el antes. Sin línea base, el retorno es una opinión.
4. Automatizar un proceso roto. Un proceso malo ejecutado más rápido sigue siendo un proceso malo, ahora a escala.
5. Dejarlo sin dueño. Un agente en producción sin responsable funcional es deuda técnica con acceso a tus datos.

Los dos primeros pasos —ordenar el proceso y documentarlo— suelen dar más retorno que el propio agente. Sobre esa parte previa escribimos en documentación funcional de proyectos IT con ayuda de IA.

Hoja de ruta en cuatro fases

Fase 1 — Elegir y medir (2 semanas). Escoge una tarea repetitiva y barata de equivocar. Mide cuánto se tarda hoy y cuántos errores tiene. Define qué sería un éxito.

Fase 2 — Piloto acotado (4-6 semanas). Un agente, un objetivo, permisos de solo lectura donde sea posible, y revisión humana de todo lo que sale. Registra cada acción desde el primer día.

Fase 3 — Producción con controles (1-2 meses). Identidad propia, secretos en un gestor, límite de pasos y de gasto, aprobación humana en lo irreversible y un dueño funcional con nombre y apellidos.

Fase 4 — Ampliar por analogía. Solo cuando las métricas aguanten dos meses seguidos. Reutiliza la misma capa de integración —ahí es donde MCP se paga solo— en lugar de montar cada caso desde cero.

Preguntas frecuentes

¿Es seguro usar un navegador con agente en una empresa?

Con controles, sí; por defecto, no. Los hallazgos publicados en 2026 sobre inyección de prompt en navegadores agénticos aconsejan tratarlos como un usuario más con permisos acotados: perfiles separados, sin acceso a sistemas críticos en la misma sesión y confirmación humana para cualquier acción que saque datos fuera.

¿Qué diferencia hay entre Perplexity Computer y un asistente normal?

El asistente responde; Computer está diseñado para ejecutar cadenas largas de trabajo apoyándose en varios modelos y en herramientas externas. La diferencia práctica es que el segundo actúa sobre sistemas reales, y eso mueve la conversación de la calidad del texto a la gestión de permisos.

¿Merece la pena para una pyme o es cosa de grandes empresas?

Merece la pena en cuanto haya una tarea repetitiva que consuma horas cada semana. Lo que no escala bien en una pyme es montar un agente distinto para cada capricho: mejor uno bien hecho que cinco a medias.

¿Hace falta MCP o basta con la API de siempre?

Puedes hacerlo todo con tu API. MCP aporta que la integración sea reutilizable entre asistentes y no haya que reescribirla cuando cambies de proveedor. Si prevés cambiar de modelo alguna vez —y lo harás—, compensa.

¿Y si el agente se equivoca con un cliente?

Por eso lo irreversible se confirma. La regla es sencilla: todo lo que sale de la organización o no se puede deshacer pasa por una persona, al menos hasta que las métricas de error sean estables durante meses.

¿Sustituye esto a herramientas de automatización como n8n?

No, se complementan. Para flujos deterministas —si pasa esto, haz aquello— una herramienta de automatización clásica es más barata, más predecible y más fácil de depurar. El agente aporta cuando el paso intermedio requiere criterio. Lo vemos a diario al sincronizar CRM y ERP con n8n.

Conclusión

Seis meses después de escribir sobre Perplexity Computer, lo interesante ya no es qué sabe hacer el agente: es evidente que sabe hacer mucho. Lo interesante es que la categoría ha madurado por los dos extremos a la vez —despliegue empresarial con control de políticas por un lado, vulnerabilidades serias documentadas por otro— y que ambas cosas apuntan al mismo sitio: el valor está en la capa de control, no en el modelo.

Si tu empresa se plantea dar el paso, el orden que recomendamos es poco épico y bastante efectivo: elige una tarea aburrida, mide cuánto cuesta hoy, dale al agente los permisos mínimos, registra todo lo que hace y pon a una persona a responder de ello. Con eso, la conversación deja de ser sobre si la IA «va a cambiarlo todo» y pasa a ser sobre cuántas horas has recuperado este mes.