User roles: ✔ All Users ✔ Application Administrator
In this article you will learn what FluidAI is, how it uses your project data, how it differs from a general-purpose AI assistant, and where responsibility sits when you act on something it tells you.
What FluidAI Is
FluidAI is the artificial intelligence built into Fluid. It is not a separate product, a chat window bolted onto the side, or a place you paste your data into. It runs inside the application you already use, on the data that is already there.
It shows up in four shapes:
Assistants answer questions. You ask, in your own words, and get an answer grounded in real project data — on a single project, or aggregated across a whole portfolio.
Quality checks review what you have written. When you save a risk, an issue or a status report, FluidAI can check it against the standards your organisation has set and tell you where it falls short.
Summaries do the reading for you. Project overviews are generated on a schedule, so a portfolio owner opening Monday morning starts from a written position rather than from a grid of numbers.
Builders do the setting up for you. Describe the schedule a project needs, or the form a board’s cards should carry, and FluidAI drafts it. Starting a request from a document you already have? FluidAI can fill in the form from it. Every draft is shown to you to review before anything is saved: a drafted schedule or form is applied only when you choose to, and values filled in from a document go into the request form for you to check and change before you submit it.
Why AI Inside Fluid Is Different
You could paste a project report into a general AI chatbot and ask it a question. People do. The difference is not how clever the AI is — it is everything it is given alongside your question.
A general assistant knows nothing about your organisation. FluidAI is assembled with it:
Your configuration. Your RAG thresholds, your impact types, your phases and gates, your status report fields. When FluidAI says a project is amber, it means amber as you defined it, not as a general-purpose assistant imagines it.
Your vocabulary. If your organisation calls them ‘work packages’ and your board columns read ‘Triage Approved’, that is the language FluidAI uses back, because those labels come from your own configuration.
Your rules. Governance criteria, prioritisation models and data checks are part of the context, so an answer can reason about compliance rather than guessing at it.
Your guidance. The standards your administrators write are what the quality checks measure against. This is the most important one, and it is covered in its own article — a check is only ever as good as the guidance behind it.
Live data, gathered at the moment you ask. The information behind most answers is read from Fluid when the question is asked. The exception is the Portfolio tab of the FluidAI Assistant on project dashboards, which answers from each project’s most recent FluidAI Project Overview — so it is as current as those overviews.
The practical consequence is that FluidAI can answer questions a general assistant cannot — ‘which projects have slipped since last month’, ‘where are our risk concentrations’, ‘does this issue meet our standard’ — because it can see across the portfolio and it knows what your standard is.
How Your Data Is Handled
Your data is not used to train AI models. The information Fluid sends with your question, and the answers that come back, are not retained by the AI service for training, and your project information does not become part of any model that another organisation could benefit from. FluidAI uses enterprise AI services under commercial agreement, not consumer chat products.
Four further points are worth understanding, because they change how much you can trust an answer:
Facts are assembled by Fluid, not recalled from memory. When you ask a question, Fluid gathers the relevant project data you have access to and sends it with your question. The answer is built from that data. FluidAI is not remembering your portfolio between conversations — it is reading what it was given, each time.
Your question steers the answer; it does not override the facts. What you type is treated as context for what to focus on. It cannot instruct FluidAI to ignore or contradict the project data that Fluid supplied. This matters most where several people share a workspace: a question cannot be used to talk FluidAI into a different set of facts.
Answers are yours. A conversation with an assistant belongs to the person who had it and is kept in their own thread. It is not published to the project or visible to colleagues. Generated project summaries are the deliberate exception — those belong to the project and everyone with access sees the same one.
Requests are logged for administrators. Each request FluidAI handles — who asked, the question and the answer — is recorded and kept for three months. Administrators can review these records, along with the thumbs up and down users give, on the FluidAI Feedback page in the Administration Console. This is how a poor answer is investigated; it is not visible to other users.
For the full statement of how Fluid handles data in its AI features, see the Fluid AI policy at link.fluid.work/ai. Every AI answer in the product links to it, next to the note that the response was generated by AI and should be reviewed.
The Human Stays Accountable
FluidAI is built on a simple principle: it drafts, reviews and summarises — a person decides. This is not a disclaimer bolted on at the end. It is designed into where the features sit.
Nothing is saved on your behalf. Suggested risks, drafted status reports, generated schedules, proposed board form fields and values filled in from a document are all proposals. They land in front of you, and they do not become project data until you accept them or submit the form.
A quality check advises, it does not block. When FluidAI judges that a risk falls short of your organisation’s guidance, it says so and explains why. The author remains free to disagree and save anyway — because they may well be right, and because a tool that blocks people teaches them to write for the tool rather than for their colleagues.
Every answer is marked as AI-generated. Wherever an answer appears, so does the reminder to review it for accuracy.
You can tell us when it is wrong. Every FluidAI result can be rated. Those ratings are aggregated for administrators, which is how a badly-performing scenario gets found and fixed.
Accountability for what goes into a status report, a risk register or a governance decision stays exactly where it was before FluidAI existed: with the person who owns it. What changes is how much of the drudgery they have to do first.
What FluidAI Does Not Do
Being clear about the boundaries is as useful as describing the capabilities.
It does not make decisions. It does not approve a gate, change a RAG status that a person owns, or close a risk.
It does not see beyond Fluid. It has no access to your email, your file shares or the internet. The one exception is a document you choose to upload yourself — for example when filling in a request form from a file — and then it reads only that document. If a fact is not in Fluid, FluidAI does not know it — and will generally tell you the information is not recorded rather than invent it.
It does not replace your judgement about people. It has no view on performance, and it should not be used to form one.
It is not always right. It works from recorded data, so a project whose information is thin or out of date produces a thin or out-of-date answer. That is often the most useful thing it tells you.
Where to Go Next
Administrators should start with Setting Up FluidAI, which covers the FluidAI Features page and what each setting turns on.
Anyone rolling FluidAI out to a PMO or change function should read Deploying FluidAI in a PMO or Change Function before switching things on widely.
Anyone writing guidance for the quality checks should read Writing Good AI Guidance first. It is the highest-leverage hour you will spend on FluidAI.