Surse
Seleccionamos las fuentes y el acceso permitido: documentos, canales y conversaciones relevantes.
Productos Cronberry
Información y coordinación Desarrollo y demostraciones
De información dispersa, contexto de trabajo.
Cronberry reúne fuentes autorizadas, conversaciones y relaciones en un espacio de investigación y coordinación. La búsqueda semántica y los agentes ayudan al equipo a encontrar lo que importa y a preparar el siguiente paso.
Cronberry
De la información al trabajo hecho.
Context
Organizamos la información por temas, relaciones y proyectos, con la posibilidad de volver a la fuente.
Coordonare
Preparamos síntesis y acciones para revisión, conectadas al flujo de trabajo del equipo.
Dónde resulta útil.
Investigación y radar temático
Seguimiento de los temas de interés y recuperación de la información relevante.
Relaciones y oportunidades
El contexto de las interacciones autorizadas, en un lugar accesible para el equipo.
La conexión con FlowMind
Exploramos el puente entre la información textual, los temas seguidos y el contexto geoespacial.
Presentamos la dirección y las funciones desarrolladas. La implementación, las fuentes conectadas y la disponibilidad se establecen en el marco de una demostración. El acceso a los datos está controlado.
Cronberry en detalle
Qué puedes hacer con este proyecto.
Cronberry es un motor de inteligencia sobre relaciones, no una herramienta de búsqueda en documentos. Parte de un archivo de conversaciones de Telegram y construye a partir de él un grafo de conocimiento en Neo4j: contactos, empresas, grupos, canales, oportunidades, campañas, productos, lugares, eventos y temas —diez tipos de entidades— vinculados mediante ocho tipos de relaciones, entre ellas «conoce», «trabaja en», «prometió» y «objetó a».
Sobre el grafo hay tres cosas que marcan la diferencia frente a un CRM: los gemelos digitales, es decir, perfiles generados a partir del historial de mensajes de una persona, con los que puedes hablar para anticipar una reacción; un optimizador que prueba dos variantes de mensaje en esos perfiles antes de enviar algo a una persona real; y un simulador Monte Carlo que ejecuta un plan de trabajo cientos de veces y devuelve una distribución de resultados, no una sola cifra.
Hay que decir claramente qué tipo de cifras produce: predicciones, no mediciones. Cuando el motor devuelve una probabilidad de respuesta o un intervalo de confianza, esas son salidas de la simulación. En el código existe la estructura que debería comparar la predicción con lo que ocurrió realmente —`AccuracyStats`, con tasa de acierto y calibración de la confianza—, pero no he encontrado en el repo ninguna serie de mediciones reales que la llene. Hasta que exista, las cifras se leen como hipótesis de trabajo.
Grafo de conocimiento basado en relaciones reales
Neo4j 5, con una ontología fija de diez tipos de entidades y ocho tipos de aristas, además de un modo en que la ontología puede ser generada por un modelo para análisis puntuales. El enriquecimiento se ejecuta en cuatro pasadas: puntuaciones de influencia de tipo PageRank, detección de comunidades mediante propagación de etiquetas, ponderaciones de arista a partir de la frecuencia de mensajes y aristas de tipo «mencionó» extraídas de los patrones `@usuario` del texto de los mensajes.
Gemelos digitales con memoria en tres niveles
Un perfil generado a partir del historial de un contacto, con memoria a corto plazo, memoria a largo plazo y memoria de relación. Tres modos de uso: conversación libre, preparación de negociación y predicción de respuesta.
Prueba de un mensaje antes de enviarlo
El optimizador reescribe un mensaje hacia un objetivo declarado y puede comparar dos variantes. La prueba de estrés lleva la idea más allá: ejecuta parámetros como aumento de precio o presión de plazo a varias intensidades y devuelve las zonas en que el contacto reacciona bien y las que conviene evitar.
Simulación Monte Carlo sobre un plan escrito
El plan entra como texto, junto con la lista de contactos, el número de iteraciones y el horizonte en días. Salen una probabilidad de éxito con intervalo de confianza, los puntos donde el plan se bloquea y el motivo de cada bloqueo. Las simulaciones tienen checkpoint, así que una ejecución larga puede reanudarse.
Los derechos de la persona, implementados como endpoints
El módulo GDPR no es una página de política: tiene exportación completa de los datos de un contacto (art. 15 y 20), borrado que actúa simultáneamente en SQLite, en Neo4j, en las predicciones y en el registro de consentimiento, con registro de borrado (art. 17), rectificación (art. 16), estado y revocación de consentimiento, registro de las actividades de tratamiento (art. 30) y un endpoint para explicar una predicción, para el requisito de transparencia del reglamento europeo sobre IA.
El coste del modelo, contabilizado
El cliente del modelo lleva un contador de coste por llamada y una caché en memoria con expiración a 3600 segundos y máximo 512 entradas, además de un limitador propio de solicitudes por minuto al proveedor. El modelo principal es Azure OpenAI, con Groq como variante rápida de reserva.
Datos y funcionamiento
Qué entra en el sistema. Qué hay que verificar.
- El corpus actual es privado y personal
- La ruta en la configuración de arranque muestra una base SQLite con el historial personal de Telegram. Eso es adecuado para desarrollo y completamente inadecuado para un servicio: una implementación en un cliente empieza con sus fuentes, con el propósito declarado y con la base de tratamiento, no con este corpus.
- Dos repositorios, un solo borrado
- Los datos están en SQLite (la fuente) y en Neo4j (el grafo), y las predicciones en un tercer lugar. El borrado a solicitud los toca a los tres, además del registro de consentimiento, y escribe un registro — porque un borrado que deja la copia del grafo no es un borrado.
- Qué protege el servicio en la entrada
- Limitación de solicitudes con cubeta de tokens: 100 solicitudes cada 60 segundos por dirección IP, global, además de límites más estrictos en los endpoints caros. Cabeceras de seguridad estrictas, con política de contenido que bloquea scripts y marcos, HSTS durante un año con subdominios y política de permisos que cierra la cámara, el micrófono, la geolocalización y los pagos. Los orígenes permitidos se configuran mediante variable de entorno.
- Lo que falta en la entrada, y sí importa
- La autenticación. En su propio plan de seguridad, el capítulo de autenticación y autorización está íntegramente sin marcar: sin validación de token en los endpoints del motor, sin roles, sin claves API almacenadas como hash, sin bloqueo ante intentos repetidos. Hasta que se resuelva, el motor funciona detrás de una red controlada, no en internet.
De la exploración a la implementación
Cómo preparamos un proyecto con Cronberry.
Primero la fuente y la base, luego el código
El primer paso no es técnico: qué datos tiene derecho a procesar la organización, con qué fin y durante cuánto tiempo. El corpus de desarrollo no se reutiliza.
Construimos el grafo con los datos del cliente
Importación en Neo4j, luego las cuatro pasadas de enriquecimiento. La ontología fija cubre el patrón de CRM en Telegram; para otro tipo de material se puede generar una específica.
Cerramos la puerta antes de cualquier exposición
La autenticación, los roles y las claves almacenadas como hash son condición de lanzamiento, no una mejora posterior. La limitación de solicitudes y los encabezados de seguridad ya existen y siguen activos.
Calibramos las predicciones con resultados reales
La estructura de medición de la precisión existe en el código. Un piloto útil significa registrar lo que predijo el motor y lo que ocurrió, hasta que las cifras tengan un historial detrás.
Preguntas que vale la pena aclarar.
¿Puedo entrar a cronberry.ai para ver?
No, y no es un problema temporal del servidor. El dominio no resuelve en absoluto: la consulta DNS devuelve NXDOMAIN, y el registro .ai responde `Domain not found` — verificado el 6 de septiembre de 2026. El servidor indicado en la documentación del proyecto, `74.248.16.185`, tampoco responde en el puerto del motor. Lo que existe y se puede mostrar: el código, que se ejecuta localmente, y una demostración preparada sobre un conjunto de datos acordado.
El sitio lo describe como un espacio de trabajo para documentos y búsqueda semántica. ¿Es así?
No, y eso es un error que estamos corrigiendo. El proyecto no es un motor de búsqueda sobre documentos. Es un motor de inteligencia sobre relaciones, construido a partir de un archivo de conversaciones: grafo Neo4j, perfiles de contacto generados a partir del historial, prueba de mensajes sobre esos perfiles y simulación Monte Carlo sobre un plan. El texto del sitio describe un producto distinto del código que existe.
¿Qué significa «probabilidad de respuesta 0,67»?
Significa una salida de simulación, no una medición. El motor ejecuta el plan cientos de veces sobre perfiles generados a partir del historial y reporta la distribución. En el código existe la estructura que compararía la predicción con la realidad — tasa de precisión y calibración de la confianza — pero no hemos encontrado ninguna serie de mediciones que la llene. Así que la cifra se usa para ordenar opciones entre sí, no como promesa de resultado.
¿Puede funcionar con los datos de nuestros clientes, no con un archivo personal?
Sí, pero ese es el primer paso de cualquier implementación, no una adaptación al final. El corpus actual de desarrollo es un archivo personal de Telegram, indicado directamente en la configuración de inicio, y no se reutiliza. La importación parte de las fuentes de la organización, con finalidad y base de tratamiento establecidas de antemano.
¿Qué pasa cuando una persona pide la eliminación de sus datos?
Existe un endpoint dedicado, y la eliminación no es parcial: afecta a SQLite, Neo4j, las predicciones generadas sobre esa persona y el registro de consentimiento, y escribe un registro de eliminación. También están implementadas la exportación completa, la rectificación, el estado del consentimiento, el registro de tratamientos y la explicación de una predicción.
¿Está listo para exponerse en internet?
No, y el motivo es preciso: la autenticación. El capítulo de autenticación y autorización de tu propio plan de seguridad está totalmente sin marcar: no existe validación de token en los endpoints del motor, roles, claves API almacenadas como hash ni bloqueo después de intentos repetidos. Lo que ya existe: limitación a 100 solicitudes por 60 segundos por IP, límites más estrictos en los endpoints costosos, encabezados de seguridad estrictos y orígenes configurables. Con la puerta de entrada cerrada, la discusión sobre el lanzamiento se vuelve real.
La documentación interna marca muchas cosas como hechas. ¿Se puede verificar?
Parcialmente, y vale la pena decirlo. La lista de seguridad remite a archivos que no existen en el repo (`swarm_api.py`, `security_middleware.py`, `gdpr_routes.py`). Sin embargo, el código correspondiente sí existe, solo que en otro lugar: `cronberry_swarm/security/rate_limiter.py`, `headers.py` y `gdpr.py`. Así que las marcas describen funcionalidad real, pero las referencias son incorrectas — las seguí en el código, no en la lista.
Ejemplo ilustrativo
Un plan de trabajo pasado por simulación antes de ser iniciado
Un escenario de uso, sin datos de cliente ni resultados comerciales atribuidos.
Situación inicial
Un equipo redacta un plan en texto — a quién contacta, en qué orden, por qué canal — y elige la lista de contactos, el número de iteraciones y el horizonte en días.
Cómo funciona
El motor ejecuta el plan cientos de veces sobre los perfiles generados a partir del historial de cada contacto, sobre el modelo de la plataforma Telegram. La ejecución tiene checkpoint, así que puede reanudarse si se interrumpe.
Rezultatul
Una probabilidad de éxito con intervalo de confianza, la lista de los pasos donde el plan se bloquea y el motivo de cada bloqueo, además del orden sugerido de los contactos. Todo son salidas de simulación, para usar como comparación entre variantes.
Ce este necesar:Sursă de date proprie a organizației, cu scop și temei de prelucrare stabilite; Neo4j pornit și graful importat; cheie de model configurată. Nu există azi o instanță publică pe care să rulezi asta.
Posibilidades de colaboración
Cronberry, en el contexto de tu organización.
Flujos internos e información
La conexión de las fuentes autorizadas, la organización de la información y la revisión de las acciones por parte del equipo, con acceso separado por roles.
Empresas privadas
Definimos un piloto en torno a un proceso real: usuarios, datos, integraciones, costes y criterios de aceptación. La ampliación sigue después de evaluar el resultado.
Instituciones y empresas públicas
Establecemos los requisitos de accesibilidad, alojamiento, protección de datos e interoperabilidad. Cualquier conexión con servicios AGE o STISC requiere la validación de la elegibilidad, el acceso y las aprobaciones.
Estos son escenarios de adaptación, no declaraciones sobre contratos o colaboraciones existentes. Las funciones propuestas se confirman en el ámbito de trabajo del proyecto.
Habla de un pilotoParte de un ecosistema.
Inteligencia geoespacial
FlowMind
FlowMind organiza mapas, fuentes públicas y productos Copernicus en un espacio de análisis.
Implementación especializadaAPI para modelos de IA
LongDay
Acceso API a modelos de IA a través de una interfaz común.
PlatformăOrganizarea muncii
Taskin
Taskin explora cómo convertir las conversaciones y el contexto de proyecto en compromisos, prioridades y pasos de trabajo.
Desarrollo y demostraciones¿Qué te gustaría que funcionara mejor?
Cuéntanos tu proceso. Juntos decidimos qué merece la pena construir, qué podemos conectar y cómo verificamos el resultado.