Flow for Education: answers to the most frequent questions

What an in-house solution involves:

• Open-ended costs: the initial investment is known, the running cost is not. Infrastructure, AI consumption, fixes and adjustments add up every year, with no ceiling.
• Long lead times: months of design, development and testing before the first user can work with it. Meanwhile models and technologies change.
• Dependence on a few people: the knowledge stays with those who built it. If they change role, the solution is left with no one who knows how to fix it.
• Endless maintenance: security updates, AI model retirements, new regulations, accessibility. Each item requires recurring work (question 3).
• Evolution at your own expense: every improvement has to be funded and developed internally. Without a budget, the solution ages.

What stays in the Institution's hands with Flow:

• Organisation: units, departments, users and roles are managed by the Institution's administrators, without going through Virsion.
• Content and permissions: who sees what, which materials the assistant may consult, how courses are organised.
• Control: consumption, costs and the action log can be consulted at any time.
• Data: it remains the property of the Institution, in its original format and exportable (question 8).
• Product direction: development priorities are agreed with customers (question 21). New features, including those born from one customer's needs, arrive as platform updates.

The Institution decides how to use the platform; Virsion takes care of running, updating and protecting it.

• Permissions: a custom chatbot normally has a single document base, the same for whoever uses it. Flow applies the individual user's permissions to every question, so the same assistant gives each person only what they are allowed to see.
• Duplicated documents: every chatbot has its own copy of the files. When a document changes or has to be deleted, every copy must be remembered. In Flow there is one document and, if it is deleted, it also disappears from AI search.
• Governance: ten chatbots mean ten owners, ten configurations and no single place to know where the data is and who accesses it. This weighs precisely on GDPR obligations.
• Costs: consumption is scattered and has no common ceiling. Flow has a budget in euros checked before every request and per-user reporting.
• Maintenance: AI models are periodically retired and replaced, and every chatbot has to be updated and retested. In Flow the update is central. The detail of what remains the Institution's responsibility is in question 3.
• Quality and accessibility: source citation, calculations performed by the software and accessible conversion of documents would have to be rebuilt in every chatbot.

A dedicated chatbot remains a good choice for a limited use on public content, for example orientation information on the website. The comparison changes when the content is confidential, the users are many and the units are different.

As things stand, an AI provider connected to Moodle offers text and image generation in the editor, plus summary and explanation of the open page. Search across materials (RAG) is not a standard feature: it comes from third-party plugins or in-house development, which the Institution chooses, installs and maintains.

• Permissions: in many RAG solutions permissions are copied into the index when the document is uploaded, and stay frozen there until the next reindexing. In Flow the filter is built by the server on every question and results are rechecked against the actual permissions: a revoked access applies from the next question. The teacher decides, file by file, what the assistant may consult.
• Answer quality: retrieving a few fragments is not enough for every question. Flow adds hybrid search with reranking, full reading and comparison of documents, counts performed by the software, recognition of formulas and tables.
• Life cycle: when a document is deleted or replaced, the index has to be updated too. In Flow this happens automatically.
• Accessibility: conversion of PDFs into accessible versions, text-to-speech and reading preferences are not part of a chatbot with RAG.
• Costs: a budget in euros checked before every request, rate limits and per-user reporting would have to be built separately.
• Scope: an assistant inside Moodle only sees what is in Moodle. Flow also covers documents that are not courses: regulations, minutes, materials from registrar's and administrative offices.

A solution of this kind is not installed once: it has to be kept alive. With a chatbot connected to Moodle this work stays with the Institution:

• Moodle updates: Moodle releases two major versions a year. At every update the plugin has to be verified and, if its developer is late or abandons it, the Institution must choose between postponing the LMS update and switching the assistant off.
• Model retirement: providers retire models on fixed schedules. Replacing the one that generates the answers requires new testing; replacing the one that builds the index requires reindexing all the materials.
• Search index: it is one more piece of infrastructure to host, monitor, back up and realign when something goes wrong.
• Documents that cannot be read: scans, formulas and complex tables fail silently. Someone has to notice and step in.
• Security and data: security fixes, assessment of the plugin and of the AI provider, update of the data processing documentation at every change.
• Quality and support: when the assistant answers badly, someone has to collect the report, understand the cause and fix it.

With Flow these activities are part of the service: the Institution uses the platform, it does not maintain it.

The two solutions are not mutually exclusive: Moodle's AI tools help with writing and reading inside the LMS, Flow answers on documents and works alongside it without replacing it (question 14).

• Same features, same permissions: the app uses the same APIs as the web version. Documents, assistant and courses follow the same access controls, enforced by the server.
• Sign-in: unlock with fingerprint or face recognition after the first sign-in with a second factor. A password change closes every session, including those on the phone.
• Use from the phone: a photo taken on the spot or an image from the gallery can be attached for the assistant.
• Notifications: push notifications with no personal data and no document content (question 5).

What an app developed on your own involves:

• Two platforms: Android and iOS have to be developed, tested and updated separately, at every new version of the operating systems.
• Publishing on the stores: developer accounts, Apple and Google reviews, data processing declarations, rules that change every year.
• Specific security: storing credentials on the device, biometrics, sessions to be revoked remotely. These are different problems from those of a website.

With Flow the app is part of the service and follows the platform's updates.

• All services are hosted in European Azure regions: West Europe (Netherlands), Sweden Central (Sweden) and Italy North (Milan), all in the European Union.
• Database and document storage are connected through private endpoints; inbound traffic goes through Azure Front Door with Web Application Firewall.
• No storage address is ever exposed to the browser: every download goes through an authenticated endpoint that checks permissions.
• Besides Microsoft, the sub-processors are listed in the annex to the contract. Mathpix recognises mathematical formulas on AWS infrastructure in Frankfurt, with data deleted right after processing; it can be disabled for the whole Institution. Google Firebase delivers the push notifications of the mobile app: no personal data and no document content travel in the messages.

• Flow uses the models through Azure: under the Microsoft service terms, prompts and answers are not used to train models and are not shared. Virsion takes on the same commitment in the contract.
• In the standard configuration Microsoft's abuse monitoring is active, which may retain prompts and answers for up to 30 days for security purposes only.
• The application reaches Azure services with managed identities (Managed Identity); the remaining secrets are kept in Azure Key Vault and never appear in code or configuration files.
• The allowed AI endpoints are defined in a closed list: the application refuses to start if an endpoint does not belong to the expected Azure domains.

• The contract includes the annexes on data processing, security measures, service levels and the list of sub-processors. Virsion is a Swiss company: the GDPR applies, where mandatory, together with the Swiss Federal Act on Data Protection.
• Any breach involving personal data is notified to the Institution within the times and in the ways set by the contract.
• Account erasure under Art. 17, with approval by the designated contact and anonymisation of personal data.
• Limited retention: conversation attachments and generated images are deleted automatically after 30 days.
• When a document is deleted, its fragments are also removed from the AI search index.
• Log of the relevant actions available to administrators; application logs contain neither document text nor credentials. Infrastructure diagnostic and security logs are kept for 90 days.

On termination the Institution has 30 days of read-only and download access to export its data; once the period has passed, the data is erased. Documents are stored in their original format, with no dependency on proprietary formats.

Export support with dedicated arrangements can be agreed in the order. Documents, prompts and assistant answers remain the property of the Institution for the whole duration of the relationship.

• The user's context (organisation, department) always comes from the authenticated session, never from parameters sent by the browser.
• Every database query is filtered by organisation directly in the query.
• The security filter on AI search is built by the server and applied before ranking; results are then rechecked against the actual permissions in the database.
• Documents have three visibility levels (organisation, department with sub-units, private) and storage is segmented by organisation.
• The automated test suite includes specific negative checks: access across different organisations, role escalation, direct access to other people's resources.

• Internal security audits with findings tracked until they are fixed.
• Analysis of known vulnerabilities in libraries (OWASP Dependency-Check) integrated into the build.
• Security review of changes and an internal register of the sensitive areas of the code, with the rules that must not be broken.
• Security headers, CSRF protection, Content Security Policy and HSTS; uploads verified on the real file format, not on the extension alone.

• Document text is delimited in the prompt and declared as untrusted data: the security instructions cannot be overridden by the content.
• The model has no tools and no executable functions: it cannot access URLs, modify data or act on the user's behalf.
• Output is sanitised before being displayed, with no scripts and no active HTML.

No system based on language models is immune by definition; Flow is designed so that an attempt of this kind cannot turn into access to unauthorised data.

• The second factor is a contractual requirement: at the first sign-in the user must set it up before being able to use the platform. They can choose an authenticator app (TOTP, with protection against code reuse) or a code by email; trusted devices are valid for 30 days.
• Temporary lockout after failed sign-in attempts and a maximum number of attempts on second-factor verification.
• Passwords hashed with BCrypt, sessions revoked when the password is changed or reset.

Today Flow handles authentication on its own. The security layer is Spring Security, which natively supports SAML 2.0 and OpenID Connect: the standards used by Microsoft Entra ID, Shibboleth and the IDEM federation.

The backend exposes a REST API layer with token authentication (short-lived access tokens and refresh tokens with rotation). An LTI connector and automatic provisioning of users from the Institution's records are not part of the current product.

• Courses organised into sections and materials, with progress per participant and the option to unlock content in sequence.
• "Ask the assistant about this course": the search scope is recalculated by the server and limited to the course materials the user can see.
• The teacher decides, file by file, which materials the assistant may consult.
• AI support for drafting course descriptions and structure, always validated by the teacher.
• Terminology dedicated to the university context and a preview of the course from the student's point of view.

The module is in production and is covered by automated tests, including security ones.

• Hybrid search (text and vector) with semantic reranking; the sources used are listed under the answer and can be downloaded by those who have permission.
• The assistant is instructed not to draw exhaustive conclusions from partial excerpts; for the questions that need it, full reading of the documents chosen by the user and comparison across several documents are available.
• Counts and sums across several documents are performed by the software on data extracted in a structured way, with the detail per document: the language model does no free-form calculation.

A language model can make mistakes: that is why Flow is built on the verifiability of the answer, not on a promise of infallibility, and the contract provides for human verification of results before they are used.

• Each plan defines a monthly AI budget in euros and a maximum number of requests: a question that would exceed the budget is stopped before being sent to the model. Where no configuration exists, the system denies rather than allows.
• The most expensive operations (analysis across several documents, AI features of courses, image generation, text-to-speech) have dedicated rate limits.
• Consumption tracked per message, conversation and user, calculated with the prices of the model actually used and net of prompt caching, which reduces costs and latency.
• Dashboard for administrators and designated contacts with monthly indicators and consumption trends.

• Every uploaded PDF is automatically converted into accessible HTML and Markdown versions, with semantic structure, tables with headers, descriptions of images and charts, and formulas in MathML readable by screen readers.
• Per-user preferences: high-legibility fonts (Lexend, OpenDyslexic), text size and spacing, reduced animations, themes designed for colour blindness.
• Text-to-speech of the answers with neural voices in Italian and English; conversation structured for screen reader navigation.
• Interface designed to WCAG 2.1 level AA and verified in a real screen reader test carried out by a blind person.

• Database, search, storage and AI models are managed services that can be sized independently.
• Heavy processing (text extraction, indexing, accessible conversion) is asynchronous and does not affect the experience of those using the platform.
• The assistant's answers are processed server-side and are not lost if the user closes the page.

• Flow is a tool for working on documents, not a preservation archive: unless otherwise agreed, keeping a backup copy of its own documents remains the Institution's responsibility, as provided by the contract.
• The standard plan relies on the Microsoft Azure service levels. Guaranteed backups, disaster recovery with recovery objectives (RPO/RTO) and application SLAs, for example availability from 99.5% and support response times, are services that can be agreed in the order or with a dedicated plan.
• Scheduled maintenance announced at least 48 hours in advance, in low-impact time windows.
• Versioned database schema: every change is tracked, repeatable and applied in a controlled way. Separate development and production environments.

• Every release goes through more than 1,100 automated tests, unit and integration, a significant share of which is dedicated to security.
• Build and tests are automated; going to production is a supervised step, preceded by validation in a dedicated environment.
• The evolution of the product is driven by customers: a project with the Institution is also the opportunity to steer the roadmap priorities towards its own context.