AI CAPABILITY INDEX
AI Capability Index (ACI) es un producto de inteligencia ejecutiva diseñado para ayudar a las organizaciones a entender la relación entre las personas, las herramientas de inteligencia artificial, el aprendizaje, la adopción y el valor organizativo. El proyecto consistió en convertir esa propuesta en una experiencia digital clara, rápida y preparada para captar oportunidades comerciales. El resultado es una landing responsive construida con React, una API privada desarrollada con Python y FastAPI, y una integración segura con Brevo para gestionar contactos mediante doble opt-in. La solución se despliega en IONOS, utiliza Nginx como servidor web y proxy inverso, y mantiene todas las credenciales fuera del navegador y del código publicado.
El reto
ACI necesitaba explicar un producto complejo sin convertir la página en una presentación excesivamente técnica. La web debía responder con claridad a cuatro preguntas:
¿Qué mide AI Capability Index?
¿Cómo se realiza la evaluación?
¿Qué obtiene una persona o una organización?
¿Cómo puede solicitar acceso o iniciar una conversación comercial?
Requisitos técnicos
- ▹Mantener una experiencia coherente en escritorio, tablet y móvil.
- ▹Permitir que todos los CTA abrieran un mismo formulario, salvo las acciones expresamente excluidas.
- ▹Enviar los datos a una lista concreta de Brevo sin exponer su API key.
- ▹Verificar que la solicitud procede de una persona y limitar el abuso del formulario.
- ▹Solicitar confirmación por correo antes de incorporar definitivamente el contacto.
- ▹Preparar la web para SEO, medición y despliegues repetibles.
- ▹Mantener una identidad visual dinámica sin perjudicar el rendimiento.
Enfoque de producto y contenido
La arquitectura de la landing se organizó como un recorrido progresivo:
Hero: presenta AI Capability Index y su propuesta principal.
What is ACI: explica el problema de negocio y las dimensiones evaluadas.
Knowledge: muestra cómo funciona la evaluación y qué áreas analiza.
Levels: comunica los cinco niveles de madurez de uso de IA.
Methodology: introduce ACI Pulse y el seguimiento de la evolución.
FAQs: resuelve las objeciones más habituales.
Pricing: presenta las modalidades de acceso.
CTA final: conduce al formulario de contacto.
La jerarquía de encabezados se revisó para que hubiera un único h1, títulos h2 para las secciones principales y h3 para sus bloques internos. Esta estructura mejora la comprensión tanto para los usuarios como para buscadores y tecnologías de asistencia.
Diseño y experiencia responsive
El frontend se construyó con React, TypeScript, Vite y Tailwind CSS. La interfaz utiliza variables CSS compartidas para colores, fondos, bordes y acentos. De esta manera, una modificación del sistema visual se propaga de forma consistente y evita la acumulación de valores hexadecimales aislados.
Decisiones principales
- ▹Contenedor central con un ancho máximo coherente en toda la landing.
- ▹Espaciado vertical uniforme entre secciones.
- ▹Navegación fija con desplazamiento suave a cada bloque.
- ▹Cuadrículas que se adaptan a escritorio, tablet y móvil.
- ▹Tarjetas de Knowledge siempre visibles, pasando de varias columnas a una sola cuando el ancho lo requiere.
- ▹Pricing con columnas equivalentes y apilado vertical cuando una tarjeta quedaría demasiado estrecha.
- ▹Levels convertido en un carrusel de tarjetas compacto y utilizable también en escritorio.
- ▹Modal de formulario accesible, con cierre claro, validación y estados de envío.
- ▹Botones con ancho automático y efecto radial de interacción.
Movimiento y animación
Las animaciones se implementaron con GSAP y se ajustaron de manera iterativa para evitar lag durante el scroll. La solución final evita animar continuamente grandes cantidades de elementos. En su lugar:
- ▹El preloader solo aparece cuando la carga real lo justifica, por ejemplo, en una primera visita sin caché o con una conexión lenta.
- ▹Los textos destacados utilizan interacciones por carácter en dispositivos con puntero preciso.
- ▹Los indicadores de Knowledge se revelan letra a letra cuando entran en pantalla.
- ▹La secuencia de indicadores está encadenada: el segundo bloque empieza únicamente cuando termina el primero.
- ▹Las palabras se mantienen completas para evitar cortes como understand entre dos líneas.
- ▹Se respeta prefers-reduced-motion, permitiendo que los usuarios que reducen movimiento vean el contenido sin animaciones innecesarias.
Esta combinación mantiene la personalidad visual de la marca sin convertir la animación en un coste constante de rendimiento.
Arquitectura técnica
La solución separa claramente la experiencia pública de la integración privada.
Usuario & React + Vite
Frontend Client
- ▹Validación en cliente de los 4 campos
- ▹reCAPTCHA Enterprise (contact_form)
- ▹Petición asíncrona a /api/contact
- ▹Respeto a prefers-reduced-motion
Nginx Proxy
IONOS Server & Gateway
- ▹Archivos estáticos en producción
- ▹Proxy inverso hacia FastAPI
- ▹Rate limiting anti-abuso
- ▹Cabeceras de seguridad HTTP
FastAPI Backend
Python Service (systemd)
- ▹Validación de origen y Pydantic
- ▹Filtrado silencioso de Honeypot
- ▹Verificación de token reCAPTCHA
- ▹Mapeo de atributos Form -> Brevo
Brevo Double Opt-in
CRM & Verificación
- ▹API Key protegida en .env privado
- ▹Envío de correo de confirmación
- ▹Validación del enlace por el usuario
- ▹Incorporación final a la lista
Frontend
El frontend se compila como archivos estáticos dentro de dist/. Nginx sirve esos archivos directamente, lo que reduce la carga del servidor y simplifica el despliegue.
- ▹React 18
- ▹TypeScript
- ▹Vite
- ▹Tailwind CSS
- ▹GSAP
Backend
El backend ofrece un endpoint limitado a la función necesaria: recibir y validar el formulario. La clave de Brevo permanece en un archivo .env privado del servidor y nunca forma parte del JavaScript enviado al navegador.
- ▹Python
- ▹FastAPI
- ▹Pydantic
- ▹HTTPX
- ▹Uvicorn gestionado mediante systemd
Infraestructura
Infraestructura alojada en IONOS.
- ▹GitHub conectado con IONOS para gestionar las publicaciones.
- ▹El repositorio contiene varias ramas y una de ellas corresponde a ACI.
- ▹Infraestructura alojada en IONOS.
- ▹Nginx para HTTPS, archivos estáticos, proxy inverso, límites de petición y cabeceras de seguridad.
- ▹systemd para mantener activa la API de FastAPI.
Flujo seguro del formulario
El formulario solicita cuatro campos obligatorios: • Name • Last name • Email • Phone number El proceso completo es el siguiente:
1. React valida que los campos tengan un formato aceptable.
2. reCAPTCHA Enterprise genera un token asociado a la acción contact_form.
3. El navegador envía los datos y el token a /api/contact.
4. FastAPI valida el origen de la petición.
5. Un campo honeypot oculto ayuda a detectar bots básicos.
6. El backend verifica el token, la acción y la puntuación de reCAPTCHA.
7. Los datos se mapean a los atributos de Brevo (ver tabla inferior).
8. El backend solicita a Brevo el envío del correo de doble opt-in.
9. La interfaz sustituye el formulario por un mensaje de confirmación.
10. El contacto entra en la lista configurada únicamente después de confirmar su dirección de correo.
| Formulario | Brevo |
|---|---|
| Name | NOMBRE |
| Last name | APELLIDOS |
| Phone number | PHONE |
Este flujo mejora la calidad de la base de datos, acredita el consentimiento y evita que el formulario sobrescriba silenciosamente datos de contactos existentes.
Capas de seguridad
La seguridad no depende de una única herramienta. Se aplicaron varias capas complementarias:
Credenciales fuera del frontend: las claves privadas solo existen en el servidor.
Archivos sensibles excluidos de Git: .env, entornos virtuales, builds y dependencias no se versionan.
Validación en frontend y backend: el navegador mejora la experiencia, pero FastAPI conserva la decisión final.
Validación de origen y CORS restringido: la API acepta el origen autorizado.
reCAPTCHA Enterprise: se verifican token, dominio, acción y puntuación.
Honeypot: las automatizaciones simples pueden descartarse sin revelar el motivo.
Rate limiting: Nginx limita el abuso repetido del endpoint.
Cabeceras de seguridad: se reduce la exposición a carga de recursos no autorizados, embedding y otros ataques comunes.
IONOS aporta protección de infraestructura, pero no sustituye estas defensas a nivel de aplicación. La combinación de ambas capas reduce el riesgo de spam, abuso de recursos y exposición de secretos.
SEO, indexación y analítica
La landing se preparó para ser entendida, indexada y medida:
Title y meta description orientados al producto.
Un único h1 y jerarquía semántica de encabezados.
Datos estructurados para la web, el software y las FAQs.
robots.txt para permitir el contenido público y excluir rutas privadas.
sitemap.xml publicado en producción.
Propiedad verificada en Google Search Console.
Google Tag Manager instalado en head y mediante fallback noscript en body.
Favicon propio de ACI.
Enlaces legales abiertos en una pestaña nueva con las medidas de seguridad correspondientes.
Proceso de desarrollo y despliegue
El trabajo se realizó de forma incremental. Cada mejora visual o técnica se comprobó primero en local y, una vez validada, se publicó en GitHub para su posterior despliegue en IONOS. Flujo de publicación:
1. Implementación y revisión en entorno local.
2. Compilación y comprobación de la versión de producción.
3. Publicación en GitHub, excluyendo secretos y archivos locales.
4. Actualización del proyecto conectado en IONOS.
5. Instalación reproducible de dependencias cuando resulta necesaria.
6. Nueva compilación del frontend en el servidor.
7. Reinicio de la API únicamente cuando existen cambios de backend.
8. Validación final del dominio y de los archivos servidos por Nginx.
La configuración de producción, las claves y los identificadores privados permanecen exclusivamente en IONOS. La conexión con GitHub permite actualizar el código sin reemplazar la configuración sensible del servidor.
Verificación y calidad
El proyecto incluye comprobaciones en varios niveles:
Build de producción del frontend.
Revisión visual en escritorio y móvil.
Comprobación de desbordamientos horizontales y proporciones de tarjetas.
Verificación de estados de animación antes y después del scroll.
Pruebas del endpoint de contacto.
Pruebas del flujo de doble opt-in de Brevo.
Pruebas de validación de origen.
Pruebas de errores controlados de proveedores externos.
Pruebas de reCAPTCHA y tratamiento de cabeceras de red confiables.
Verificación de respuestas públicas 200 OK después de cada despliegue.
Resultado
El proyecto terminó con una base preparada para producción y evolución continua:
Una narrativa de producto clara y estructurada.
Una experiencia responsive consistente.
Interacciones visuales con personalidad y rendimiento controlado.
Un formulario conectado a Brevo sin exponer credenciales.
Verificación de usuarios mediante reCAPTCHA y doble opt-in.
SEO técnico, sitemap, robots, schema y medición instalados.
Un proceso de despliegue repetible desde GitHub hacia IONOS.
Separación clara entre código versionado y configuración privada.
Más que una landing aislada, la solución funciona como la primera capa operativa de ACI: presenta el producto, educa al usuario, captura interés y protege la calidad de los contactos que llegan a la organización.
Aprendizajes principales
La animación debe apoyar la lectura
Las primeras aproximaciones vinculaban demasiados cambios visuales al scroll y podían producir lag. Pasar a animaciones puntuales, activadas una sola vez y respetuosas con las preferencias del usuario, mejoró la experiencia sin perder carácter.
La seguridad del formulario empieza por la arquitectura
Ocultar una API key no consiste en ofuscarla en React. La decisión importante fue crear una API privada que actúa como intermediaria, valida la petición y controla qué puede enviarse a Brevo.
El responsive necesita decisiones específicas
No fue suficiente reducir tamaños. Algunas secciones cambiaron de cuadrícula, otras se convirtieron en carrusel y otras se apilaron. Diseñar para cada contexto produjo una interfaz más accesible que una simple versión escalada del escritorio.
Un despliegue fiable evita cambios innecesarios
Separar frontend, backend y configuración permite actualizar solo lo que ha cambiado. Una mejora visual no necesita reiniciar la API; una modificación del backend no debe reemplazar el .env; y Nginx solo debe recargarse cuando cambia su configuración.