El vocabulario que usamos.

La plataforma de agentes de IA de Salesforce, sucesora de Einstein. Crea agentes que consumen Data Cloud como fuente de contexto y actúan sobre Sales, Service y el resto de las clouds. No es un chatbot — es una capa de ejecución.

La capa de contexto operativo de Salesforce. Materializa perfiles en tiempo real, alimenta Agentforce, Marketing y Sales. No es solo un CDP — es una base. Tratarlo como "solo un CDP" deja valor sobre la mesa.

El núcleo de ventas de Salesforce. Pipeline, oportunidades, cuentas, contactos, automatización del proceso comercial. Fue el producto original de la plataforma; hoy funciona mejor integrado con Data Cloud y Agentforce.

El producto de atención al cliente de Salesforce. Casos, omnicanal, SLAs, base de conocimiento. Bien implementado, se convierte en el lenguaje común entre operaciones, calidad y producto.

Plataforma para unificar la identidad del cliente, segmentar y activar en canales de marketing. Categoría de producto que Data Cloud trasciende — sigue siendo útil como concepto, pero insuficiente como definición de la capa de datos.

A la vez el modelo de datos armonizado de Data Cloud (objetos canónicos como pedidos, casos, contactos) y la tesis estratégica de Salesforce — cada interacción ocurre sobre el mismo perfil unificado.

Paso obligatorio antes de cualquier configuración de Salesforce. Documenta pasos, excepciones, reglas y SLAs en un formato legible tanto por humanos no expertos como por LLMs. Saltárselo es la mayor fuente de retrabajo en proyectos de CRM.

Herramienta de transformación de datos que se convirtió en el estándar de facto en modelado analítico. Usa SQL + Jinja + tests + documentación como código. La ganancia real no es el modelo — es la documentación versionada.

ETL extrae, transforma y luego carga — generando cuellos de botella en servidores intermedios. ELT carga en bruto al warehouse y transforma allí — usando el motor que ya existe. La inversión es estructural, no estética.

Stack típico hoy: ingesta (Fivetran/Airbyte) → warehouse (Snowflake/BigQuery/Databricks) → transformación (dbt) → BI (Tableau/Looker). No es una prescripción — es vocabulario común entre ingenieros de datos en 2026.

Warehouse: datos estructurados, consultas SQL, foco analítico. Lake: datos en bruto en formatos variados, foco en almacenamiento barato. El lakehouse intenta ambos — funciona cuando el problema lo justifica, perjudica cuando es la respuesta por defecto.

Acuerdo formal entre productor y consumidor de un activo de datos: esquema, garantías de calidad, política de cambios. Reduce el "el pipeline se rompió porque alguien renombró una columna" — el problema más común en equipos de datos.

Enfoque de modelado (Kimball) con tablas de hechos y dimensiones. Sigue siendo válido en 2026 — no como única arquitectura, sino como patrón para la capa analítica de consumo.

Cultura donde personas de negocio crean sus propios análisis a partir de modelos confiables. Falla cuando el modelo es malo — cada área crea su "versión final" y la empresa pierde la única fuente de verdad.

Plataforma de visualización y BI (Salesforce). Excelente para exploración visual rápida sobre datos bien modelados. No sustituye al modelado ni a la decisión de negocio — visualiza, no piensa.

Patrón en el que un LLM recupera fragmentos relevantes de una base externa antes de generar la respuesta. Reduce la alucinación y permite usar conocimiento actualizado. Lo difícil es "recuperar bien", no generar.

Modelo de lenguaje entrenado con grandes corpus de texto (GPT, Claude, Gemini). Útil como capa de razonamiento en pipelines de IA; peligroso como única fuente de verdad. Tratarlo como un junior humano muy bien informado.

Representación numérica (vector) de texto, imagen u otros datos. Permite calcular similitud semántica. Base de la búsqueda vectorial y del RAG. La calidad del embedding determina la calidad de la recuperación.

Base optimizada para búsqueda por similitud vectorial (Pinecone, Weaviate, pgvector). Componente típico de RAG. La elección depende de la escala, la latencia y el tooling existente — no del hype.

Continuar el entrenamiento de un LLM ya listo con datos del dominio. Caro, lento y rara vez el primer movimiento. RAG y prompt engineering suelen entregar el 80% del valor al 10% del coste.

Disciplina de escribir instrucciones para LLMs que producen salidas confiables. Versionado, probado y medido — no improvisado. Casi siempre el primer experimento antes de RAG o fine-tuning.

Proceso de medir el desempeño del agente en casos reales y de borde. Incluye precisión, tipos de error, tasa de escalado y coste por interacción. Sin evaluación rigurosa, un agente en producción se vuelve un pasivo silencioso.

Respuesta del LLM que suena plausible pero es factualmente errónea. RAG y prompt engineering reducen; nunca eliminan. Por eso la gobernanza y el human-in-the-loop son parte del diseño, no sobrecarga.

Conjunto de prácticas para operar IA de forma responsable: logs de cada interacción, auditoría de decisiones, kill switch, política de retención, proceso de incidentes. No es sobrecarga — es lo que separa un proyecto que sobrevive a un nuevo consejo.

Modelo de engagement de Kliente 360 para proyectos de IA — cuatro semanas de Mapear, Prototipar, Validar y Decidir. Entrada de bajo compromiso para validar la tesis antes de un proyecto largo.

El método de entrega de Kliente 360. Cinco verbos aplicados en las tres prácticas: Mapear, Prototipar, Validar, Implantar, Sostener. Un híbrido entre consultoría estratégica, proyecto de tecnología e implantación rápida de IA.