Evaluating Flexday AI
Evaluating Flexday AI
For a buying committee - what Flexday AI is, which pages answer each reviewer's questions, and what to request from Flexday during due diligence.
- Everyone
Last reviewed
This section is for the people who decide whether Flexday AI can be trusted with an organisation's people, data and processes: security, architecture, privacy, AI risk, procurement and the executive sponsor. Each page describes a mechanism, not an adjective, and links down to the governance or architecture page that holds the detail. Every statement on these pages is recorded with the source code or infrastructure definition that backs it. What the platform itself cannot show, such as certifications, service levels and contract terms, is listed as something to request from Flexday.
What Flexday AI is
Flexday AI builds business software from a description. A person writes what they need in plain English, optionally attaching files, and the Builder, an AI engine, creates a working Solution: usually a web app, plus whichever datasets, document collections, automated workflows and AI assistants (Agents) the request needs. The Solution is then refined by conversation, and published, run and governed in the Studio.
Builders work in the Studio. The people who use what was built reach it through the generated web apps, an API called the Flex Gateway, or Microsoft Teams, signing in, where the Solution requires it, through an identity provider its owners choose; they never need a Studio account. The platform runs as a service operated by Flexday, or as a dedicated deployment in your own cloud account.
For a buying committee, the question is less what it can build than how it is controlled. Each workspace's Solutions and resources are kept apart by row-level security in the database, people act within workspace and Solution roles, changes to audited records are attributed to the person who made them, every completed model call is metered, and Agents can use only the tools they are granted. The pages below explain each mechanism, where to see it in a trial, and what stays your organisation's decision.
Reading paths by role
| Reviewer | The questions they ask | Pages that answer them |
|---|---|---|
| CISO or security architect | How are sign-in, isolation, encryption, staff access and the development process controlled? What would our questionnaire say? | Security overview, Security questionnaire, answered, Data isolation, Secrets and encryption |
| Enterprise architect | Where can it run? How does it fit our identity provider, cloud and business applications? How does it scale and recover? Can we leave? | Deployment options and data residency, Fit with your technology stack, Reliability and business continuity, Portability and exit |
| Data protection officer | What personal data is held, where, for how long and who can see it? What reaches an AI model provider? How is data exported or deleted? | Data protection and privacy, Data lifecycle and portability, How the platform supports your compliance |
| AI risk or governance lead | How is AI limited, tested, grounded and monitored? Who stays in control? | Responsible AI, AI safety, Audit, usage and cost |
| Procurement and vendor risk | Which documents and commitments must come from Flexday rather than from the product? | The due-diligence checklist below, the documents to request, How the platform supports your compliance |
| Executive sponsor and functional users | What will it do for our teams, what does a proof of concept look like, and how do we measure success? | Running a proof of concept, Platform at a glance, the Service Desk Copilot |
The due-diligence checklist
The platform's mechanisms are described in this documentation and can be checked in a trial. Facts about Flexday as a company cannot, so ask for them directly.
Documents to request
- Attestations. Any current third-party attestation reports or certificates Flexday holds (for example SOC 2 or ISO/IEC 27001), with their scope and period.
- Security testing. The summary of the most recent independent penetration test, and how findings are tracked to closure.
- Policies. The information security policy set: access control, vulnerability management, secure development, incident response, staff vetting and security training.
- Service levels. The availability commitment for the hosted service, support hours and response targets, maintenance windows and how incidents are communicated.
- Continuity. The business continuity and disaster recovery plans, the recovery objectives Flexday commits to, and the date and outcome of the last recovery test.
- Data protection terms. The data processing agreement, the current list of sub-processors with their locations, and the terms under which each AI model provider processes your data.
- Commercial terms. Pricing, contract length, exit assistance and liability, and evidence of insurance cover.
- References. Customer references comparable to your organisation, if Flexday can provide them.
Sessions to request
- An architecture walk-through with Flexday engineers, using these pages and your requirements.
- A security review in which your questionnaire is answered against the platform's code and infrastructure, starting from the answered questionnaire.
- A data protection review with your data protection officer: the data inventory, where processing happens, and the data processing agreement.
- An AI risk review: guardrails, evaluations and grounding, demonstrated on your own documents.
- A proof of concept on a real process of yours. See Running a proof of concept.
What to verify yourself
Each governance page has a What an evaluator can verify section: where in a trial to look to confirm the control it describes, for example identity and access, data isolation and AI safety.