Privacy Policy

1. Reading this policy as a conversation

VERONA AI LIMITED — trading as Verona AI, and called “we” or “us” below — builds AI agents that answer for small businesses. A reception agent picks up enquiries, a paperwork agent reads what customers send in, and an operations agent carries the routine follow-through. Everything we hold about a living person arrives through one of those three doors, or through an ordinary business exchange with us.

Most privacy notices are filed by legal concept, which is convenient for the drafter and slow for the reader. We have filed this one the way the work actually happens. A message lands; the agent works out what it means; something gets done; a colleague may take over; a record is left behind. Five turns, in the order they occur, each carrying its own annotation: what exists at that moment, who owns the decision, what permits it, and when it goes away.

Sections 3 to 7 walk those turns. Sections 8 and 9 cover the separate conversation you have with Verona AI itself — as an enquirer, a subscriber or an app user. Sections 10 onward hold the framework that wraps around every turn equally: bases, recipients, geography, retention, security, rights.

1.1 What this covers

The website at veronaai.co; the signed-in Verona AI platform where agents are configured and supervised; the agents in operation, including the dialogue they hold and the files they read; the companion mobile applications for iOS and Android once each is published; and our day-to-day correspondence. Sites we link to run their own notices. Businesses that deploy an agent run theirs, and section 2 explains why that distinction decides almost everything.

1.2 Documents that sit alongside this one

• the Terms of Use, together with whatever order form or subscription agreement a business customer has signed;
• the Cookie Policy, which itemises the storage this website places on a device;
• our Data Processing Agreement, incorporated into every customer contract, carrying the Article 28 UK GDPR clauses, the processing description, the security schedule and the live sub-processor register — write to ask@veronaai.co for a copy; and
• whatever short notice appears at the point where data is collected, which adds detail and never contradicts what is written here.

A signed customer contract wins over this page for that customer's own processing. For everyone else, this page governs.

2. Who is accountable at which turn

Data protection law splits responsibility in two. A controller settles the purpose and the means, and answers to the individual for both. A processor executes a controller's written instruction, may not repurpose anything, and hands the material back or destroys it on command.

Verona AI occupies both positions depending on which conversation you mean. The conversations our agents hold for a shop, a clinic or a practice belong to that business: it chose the channel, wrote the brief and set the scope, so it is the controller and we run the machinery underneath. The conversation you have with Verona AI itself — enquiring, subscribing, raising a ticket — belongs to us.

2.1 The controller, when it is us

VERONA AI LIMITED
Registered in Northern Ireland, Company No. NI738464
Our registered office address sits against NI738464 in the Companies House register, and formal documents should be served there.
Email: ask@veronaai.co

Data protection accountability rests with the company's directors rather than a delegated function. Put “Data protection” in the subject line and any question, rights request or incident report reaches the right desk. Anything sent by post belongs at the registered office, marked for our Data Protection Lead.

2.2 A designated Data Protection Officer

Article 37 UK GDPR reserves the statutory DPO appointment for public authorities, for organisations whose core work is large-scale systematic monitoring of people, and for those handling special category or criminal offence material at scale. Verona AI is a private company; agents run inside individual small businesses rather than as a surveillance service; and the product is not designed around sensitive categories. On that footing the appointment is not triggered. We revisit the question as conversational volumes grow, and if the answer changes we will appoint someone, publish their contact route in this section and register them with the ICO.

2.3 Registration and representation

The Data Protection (Charges and Information) Regulations 2018 require most UK organisations to pay an annual data protection fee. We pay it and keep our entry live wherever the Regulations apply to what we do. Ask at ask@veronaai.co for our current standing and we will tell you plainly. Our establishment is in the United Kingdom and we do not aim services at people in the EEA, so no Article 27 representative has been appointed; one would be named here before we began offering the Services in the EEA.

3. Turn one — the greeting

Somebody opens a chat window, replies to an email address, or sends a message on a channel a business has connected. The agent greets them. That single exchange already generates a record.

3.1 What exists after the first message

• The words themselves — the full text of what the person wrote and what the agent said back, kept verbatim rather than summarised, because a partial transcript is worse than none when a dispute arises;
• The route in — the address, handle, web session reference or number the message arrived on and came from;
• Anything attached, if the business has permitted attachments on that channel;
• Timing — when each line landed, and how long the reply took;
• Connection details — an IP address where the channel discloses one, plus browser and device type for web chat.

Nothing is lifted from the sender's device beyond the message they chose to send. We never buy, scrape or append third-party data to fill out a picture of who somebody is.

3.2 Saying that the greeting came from software

People are entitled to know they are addressing a machine, and our product enforces that rather than hoping for it. An agent opens by naming itself as an AI assistant, in wording a business may adapt but cannot switch off. Web surfaces carry a standing notice identifying the business behind the assistant. Agents are instructed never to adopt a human identity, and never to deny what they are when challenged. Businesses must also link their own privacy information from the channel so the person can see who the controller is. Any additional disclosure duty a regulated sector imposes stays with that business.

3.3 Who owns this turn

The business being contacted. It selected the channel, wrote the agent's brief and decided the conversation should happen at all. Verona AI processes the greeting on its documented instruction under an Article 28 agreement, and for nothing else.

4. Turn two — understanding

Between the question and the answer sits the part customers rarely see: the agent works out what has been asked and assembles a reply.

4.1 What the platform assembles

A request is put together from four ingredients — the instructions the business wrote for its agent, the items pulled from that business's own knowledge base, the recent lines of the conversation in hand, and descriptions of any tools the agent is permitted to call. That package goes to a large language model, which returns a draft. The draft is then measured against the business's rules before a word is sent or a step is taken. Retrieval never crosses a tenancy line: an agent reaches its own business's knowledge and its own conversation, and nothing else on the platform.

4.2 The model providers

We buy language model capacity rather than training foundation models, so the assembled package travels to a provider working as our sub-processor. Selection is not casual. A provider must be contractually barred from using what we send to train or refine its own models; must hold inputs and outputs only long enough to return a response and satisfy its own abuse-monitoring duties, with zero-retention or short-retention settings enabled wherever they exist; must be engaged under written Article 28 terms with a valid transfer route (section 12); and must meet a security standard we assess before signing and revisit afterwards. Which providers are live at any moment is recorded in the sub-processor register attached to the DPA, available from ask@veronaai.co — kept there so that it stays accurate between revisions of this page.

4.3 Conversations are not training material

A business may separately switch on learning from its own conversations to sharpen its own agent. That improvement stays sealed inside that tenancy, is never pooled with anyone else's, and starts in the off position.

4.4 What the model can and cannot be trusted with

Language models produce plausible text, which is not the same as correct text, and carefully written input can push them off course. We design around that with scope limits, restricted tool access, approval gates and escalation routes. What we will not do is promise that an agent never gets anything wrong. Businesses have to read agent output before acting on it where the consequences are legal, financial, clinical or otherwise serious, and the Terms of Use put that obligation in writing.

5. Turn three — action

Understanding turns into something happening: a booking is placed, an invoice is read and filed, a record is updated, a draft is prepared for approval.

We do not aim an agent at anything. The business configures it, chooses which channels and systems it may reach, and carries the responsibility for having a lawful basis and for telling its own customers.

5.1 The line an agent may not cross

Neither we nor any agent we supply is permitted to reach a decision by automated means alone where that decision carries legal effect or similarly significant consequences for a person, within the meaning of Article 22 UK GDPR. This is enforced in the product, not merely asserted on a webpage.

Oversight is wired into four places. Scope — the business defines the permitted actions and the callable tools, and anything beyond them escalates. Approval — consequential steps wait for a person to confirm them. Handover — anyone in a conversation can ask for a human, which is turn four. Review — activity is logged so staff can see what was done, correct it and step in. The people doing that overseeing are the business's own staff, who hold both the authority and the context to change an outcome, which is what makes oversight meaningful rather than ceremonial. Configuring an agent to make Article 22 decisions breaches our DPA, and we may suspend an agent set up that way.

Nobody is profiled here for advertising, credit scoring, insurance pricing or behavioural targeting. Were a future capability ever to involve solely automated decisions, this page would be revised before that capability was switched on, to identify the ground relied on, describe the logic and the likely consequences, and set out the route to human intervention, to putting your view, and to contesting the result.

6. Turn four — handover

Some conversations should not be finished by software, and the product is built on that assumption rather than resisting it.

An agent passes the conversation to a person when it is asked to, when the request sits outside its configured scope, when its confidence drops, when a complaint or a signal of vulnerability or safeguarding appears, or when the business's own rules say so. The transcript travels with the handover so nobody has to start again. Asking in plain words is always sufficient, and no explanation is owed.

6.1 Redaction before anything is stored

Chat boxes attract things nobody would write on a form, so several protections run by default. Card numbers, security codes and anything shaped like a password or key are detected and replaced with a marker before the line is written to storage. Businesses can add their own patterns to be masked at the point of capture. Behavioural rules stop an agent asking for payment details or sensitive categories and steer those matters onto a secure route instead. And an administrator can redact or delete any transcript by hand afterwards. None of this is a guarantee — an agent cannot prevent someone from volunteering something in free text — and section 17 covers what happens when they do.

6.2 When one of us needs to read real content

Occasionally an engineer here has to look at genuine material: a fault has been reported, a safety concern raised, or a fix needs verifying. Access in those cases is confined to the fewest people who can resolve the problem, is recorded, is used for that purpose alone, and works from redacted or synthetic material wherever the problem allows it. There is no routine browsing of customer conversations, and no internal corpus of customer content is assembled.

7. Turn five — review and wrap-up

The conversation ends and a record remains. What survives, for how long, and under whose control is the last annotation.

7.1 What the record contains

Transcripts and extracted fields live on our infrastructure, encrypted in transit and at rest, and partitioned per business so that no agent can reach another business's material. Alongside them sit the working traces from turn two — which knowledge items were retrieved, which tools were called, whether a confidence or safety threshold fired, and whether the conversation was handed over and to whom.

Destruction removes the material from live systems straight away and clears it from encrypted backups as those age out on their normal rotation, which never runs beyond 35 days. Throughout that window the product cannot read it and nothing uses it.

7.2 Aggregate figures

We produce operational numbers from the platform — message volumes, response times, error rates, capacity trends. They are aggregated and stripped of identifiers before anyone looks at them, hold no conversation content, and cannot be traced back to an individual.

7.3 What we owe the controlling business

Our DPA commits us to: acting only on documented instructions; flagging an instruction that looks unlawful; binding everyone with access to confidentiality; maintaining the Article 32 measures in section 14; taking on sub-processors only with authorisation and notice (section 11); helping with data subject requests, impact assessments and ICO consultations; reporting incidents promptly (section 15); destroying or returning material when the contract closes; and supplying whatever is needed to demonstrate compliance, audit rights included.

8. Conversations you have with us directly

Separate from anything an agent handles, you may deal with Verona AI yourself. Here we are the controller, and this website carries no forms at all — every route is an email link, so we receive exactly what you decided to send.

The inventory tables below are wide. Scroll them sideways to reach every column.

On the balancing tests. Every row leaning on Article 6(1)(f) has a written legitimate interests assessment behind it, naming the interest, testing whether it could be achieved with less, and setting it against your rights and what you would reasonably expect. In each case the fields are few, the period is short and nobody is profiled. Ask at ask@veronaai.co for a summary of any of them; section 19 explains how to object.

The website carries no analytics script, no advertising pixel, no marketing tag, no session replay, no split testing, no third-party chat widget and no embedded social tracker. Nothing here builds a picture of who is browsing.

One request: please keep passwords, card numbers and health details out of support messages. If any arrive we strip them once the issue is closed, and for credentials we will ask you to change them.

9. The Verona AI mobile apps

This section covers every mobile application VERONA AI LIMITED publishes on the Apple App Store and on Google Play — including the Verona AI companion app, through which an owner supervises agents, approves pending actions, sends in documents and picks up a handover. Any difference specific to one app appears in that store listing and in an in-app notice before the feature is used. For the apps we are the controller of your account, device and diagnostic data; the customer material you view inside them stays governed by sections 3 to 7.

9.1 Permissions

Every permission is optional and none is requested up front. Each prompt appears the first time you reach for the feature that needs it, with an explanation attached.

Withdrawing a permission takes effect at once; if a feature depends on it, the app explains and offers to open the relevant settings screen.

9.2 On the device, and on our servers

9.3 Analytics, crash reports and identifiers

In-app analytics go no further than the telemetry described in section 8: which screens were opened, which features were used, how long an operation took, whether it succeeded — recorded against an internal installation reference and, after sign-in, your account. Analytics events carry no conversation content, no document content and nothing you typed. There are no third-party advertising or attribution SDKs in our apps, and nothing goes to an ad network. Crash reports carry a stack trace, app and OS version, device model, memory and storage state and the screen in use, and may carry an internal reference so that we can see whether one person keeps hitting the same failure — never conversation content, documents or credentials. Crash data reaches us through App Store Connect, Play Console and our own error reporting, is held 12 months, and is read only to fix the fault.

The references we use are an internal installation identifier that resets when the app is reinstalled; the push token Apple or Google issues if you enable notifications, used only to deliver them; and transient values such as device model, OS and build version, locale and time zone. Advertising identifiers are not collected or stored — neither the IDFA nor the Android Advertising ID nor any substitute — devices are not fingerprinted, and nothing links you to what you do in other companies' apps or websites.

9.4 Tracking prompts, and the Play Data Safety form

Apple's definition of tracking is joining data gathered in our app to data gathered elsewhere by other companies for targeted advertising or advertising measurement, or passing it to a data broker. Our apps do none of those things, which is why no App Tracking Transparency prompt is shown: there is no tracking to seek permission for. Our App Store privacy labels are compiled from this page and declare collection for app functionality and analytics only. If a future capability crossed into tracking, this policy would change, the labels would change, and the ATT prompt would be shown before anything began.

Each Google Play listing's Data Safety declaration is compiled the same way: it lists the categories in sections 8 and 9, records that data is encrypted in transit, records that nothing is sold or shared for advertising, and links to the deletion route in section 21. Where a store listing and this page disagree, this page describes what actually happens and we will correct the listing — please point it out at ask@veronaai.co.

9.5 Subscriptions bought inside an app

Purchases made in an app are billed by Apple or by Google, not by us. Payment details are entered with them under their terms, and your card number, expiry date and security code never reach us. The store returns a receipt or purchase token, the product identifier, the purchase and expiry dates and the renewal state; we store those to unlock the right features and keep your subscription aligned with what has been paid. The store also tells us about renewals, cancellations, retries, refunds and grace periods, and supplies aggregated sales reporting we use for the accounts. Refunds for store-billed purchases follow that store's policy — the Terms of Use cover this, including your statutory cancellation rights. Subscriptions sold directly are invoiced through our accounting provider, and only the billing fields in section 8 are held.

10. Every lawful basis in one place

The tables above name a basis row by row. Gathered together, four grounds carry everything we do as controller, and a fifth position applies where we are processor.

11. Who else touches a conversation

Personal data is not sold here, and nothing goes to an advertising network or a data broker. Disclosure runs only to the recipients below, each bound by a written contract carrying data protection terms, and only as far as the stated purpose requires.

On a business transfer this page keeps applying until you are told otherwise, you will be notified and offered whatever choices the law gives you, and customers get advance notice under the DPA.

11.1 Changing a sub-processor

A recipient list only earns its place by being true. This section is revised whenever a recipient joins or leaves, and a dated sub-processor register in the DPA names each one, its function, its processing location and the transfer route that covers it. Anyone can ask ask@veronaai.co for the current version.

Where we act as processor the DPA gives customers general written authorisation for sub-processing with the safeguards Articles 28(2) and 28(4) require. Adding or swapping a sub-processor that will handle customer material carries at least 30 days' written notice to affected customers. A customer with a reasonable data protection objection may raise it inside that window; we look for an alternative, and where none works they may end the affected service without penalty for the remainder of the paid term. Every sub-processor signs terms no weaker than our own obligations, and we stay liable for what they do.

12. Where the words physically sit

We are a UK business and we favour UK or EEA processing wherever it can be had. Some providers are headquartered in the United States and may process outside the UK. One of the routes below is in place before any such transfer happens.

Signing the paperwork is where the work starts, not where it stops. Where the Agreement or the Addendum is relied on we complete a written transfer risk assessment covering how sensitive the data is, what the destination's laws permit by way of government access and what redress exists there, the recipient's own record and transparency reporting, and the supplementary measures in place — encryption in transit and at rest, key handling, access control, and cutting down what crosses a border at all. Assessments are revisited when circumstances shift and can be shared with customers on request.

For material held in our processor role we aim at UK or EEA storage and set regional controls wherever a provider offers them. Part of the pipeline — the model call described in section 4.1 in particular — may run outside the UK depending on which provider and region are in use. The DPA states the current position service by service, and customers hear from us before it changes. To ask which route covers a particular transfer, write to ask@veronaai.co.

13. How long each item survives

Nothing is kept beyond the purpose that justified collecting it, plus whatever period the law imposes. Periods that run “from the end of the relationship” start at the later of the final transaction and the final substantive contact.

At the end of a period the record is destroyed or irreversibly anonymised. Where technical constraints prevent immediate destruction we isolate the material, stop using it, and destroy it at the first opportunity.

14. Keeping conversations safe

Article 32 UK GDPR asks for security proportionate to the risk. This is the working answer.

14.1 Technical measures

• Encryption in transit — TLS 1.2 or higher with current cipher suites, HSTS, and plain HTTP redirected, on internal hops to sub-processors as well as public ones.
• Encryption at rest — databases, object storage and backups encrypted using provider-managed keys with platform rotation.
• Least privilege — access granted by role only to those who need it, reviewed when a role changes and at least once a year; multi-factor authentication on administrative access; no shared administrator logins.
• Tenant separation — customer material partitioned logically, with every access path scoped to a single tenancy.
• Secrets handling — credentials in a managed secret store, never in source, rotated when access changes or compromise is suspected.
• Logging and monitoring — authentication events, administrative acts and exports recorded, retained per section 13, and examined when an anomaly surfaces.
• Backups — encrypted, on a rotation of no more than 35 days, with restores tested rather than presumed.
• Environment separation — development and test environments carry no live customer material; testing runs on synthetic or redacted data.
• Perimeter — web application firewall, bot management, rate limiting and DDoS protection in front of anything public.
• Minimisation by design — masking applied at the moment of capture (6.1), short default periods, and a model request carrying nothing the answer does not need.

14.2 Organisational measures

• Confidentiality — everyone working on the product, employed or contracted, is under written confidentiality obligations that outlast the engagement, as Article 28(3)(b) requires.
• Training — data protection and security awareness at induction and refreshed afterwards, covering phishing and the handling of customer content.
• Secure development — peer review before release, dependencies monitored and patched, extra scrutiny on authentication and data-handling changes, and no production credentials in the codebase.
• Supplier diligence — security documentation, attestations, onward subprocessing, transfer routes and incident commitments examined before engagement, an Article 28 agreement executed, and periodic reassessment after.
• Device security — full-disk encryption, automatic locking, current operating systems and remote wipe on company hardware.
• Joiners and leavers — access issued by role and withdrawn the day an engagement ends.
• Records — a documented incident procedure with named owners and the timings in section 15, alongside a record of processing activities, the legitimate interests and transfer risk assessments, an incident register and impact assessments where they are required.

14.3 Telling us about a weakness

No system is beyond reproach. If you think you have found a vulnerability, send it to ask@veronaai.co with enough detail for us to reproduce it. We will confirm receipt, keep you posted on what we find, and take no action against anyone who reports a genuine issue in good faith without reaching into, altering or keeping other people's data.

15. When a conversation escapes

A personal data breach is a security incident causing accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. Our handling follows Articles 33 and 34.

• Raising it. Anyone here who suspects a breach takes it straight to the director accountable for data protection, with no triage layer in between, because the Article 33 clock starts at awareness rather than at conclusion. Reports arriving from outside at ask@veronaai.co are handled identically.
• Containing and assessing. Containment leads — credentials revoked, systems cut off — and assessment follows it: which data, belonging to whom, in what quantity, at what sensitivity, encrypted or not, and carrying what risk of harm. Every incident goes into the register with its facts, effects and remedial steps, whether or not it is notifiable, because Article 33(5) requires that record either way.
• Telling the ICO. Where a breach we control is likely to risk people's rights and freedoms, we notify the ICO without undue delay and inside 72 hours of becoming aware. If the whole picture is not assembled by then we file what we have and complete it in stages rather than let the deadline pass. Where we conclude a breach is not notifiable, the reasoning is written down.
• Telling you. Where the likely exposure to your rights and freedoms reaches high risk, you hear from us without undue delay, in ordinary language: the event itself, its probable consequences, our response, the steps available to you, and a name to contact.
• Where we are processor. The affected business hears from us without undue delay — our internal target is 24 hours from awareness, and always in time for them to meet their own 72-hour duty — with the nature of the incident, the categories and rough numbers involved, the likely consequences, the measures taken and a named contact. We then help with their notifications. We do not notify the ICO in a customer's name unless instructed, because that call belongs to the controller.
• Afterwards. Anything of substance gets a review — what let it happen, what detection missed, what stops a repeat — and the resulting actions are tracked until they are closed.

16. Conversations involving children

Verona AI sells to businesses. The website, the platform and the apps are meant for adults at work, account holders must be 18 or over, and our store listings are not aimed at children. As controller we do not knowingly gather children's data.

Standing as processor the question gets harder, since the businesses we serve deal with the public, and children are part of the public. The DPA therefore stops a customer deploying an agent on a service directed at, or likely to be reached by, children without first assessing that use against the ICO's Age Appropriate Design Code and completing an impact assessment. Deployments of that kind must use age-appropriate language, collect the minimum, carry no behavioural profiling, and escalate to a person on a low threshold. Nothing from those conversations is used for our own ends and none of it goes near model training. If you believe we hold data about a child that ought to be removed, write to ask@veronaai.co and we will act quickly, alerting the controlling business at the same time where we are processor.

17. When something sensitive is typed

Wearing the controller hat, Article 9 UK GDPR special category material has no place in what we handle. There is no field for it, we do not ask and we do not infer. Two narrow situations exist: health information you choose to give us so that we can make a reasonable adjustment, handled on Article 9(2)(a) explicit consent; and material genuinely needed to bring or defend a legal claim, handled on Article 9(2)(f). For criminal offence data under Article 10, which we never seek, the only condition we would rely on is paragraph 33 of Part 3 of Schedule 1 to the Data Protection Act 2018. Where a Schedule 1 condition calls for an appropriate policy document, one will be prepared and maintained.

As processor it can arrive unbidden: someone writing to a clinic's reception agent may mention a diagnosis, and a submitted file may contain a fit note. Where that happens we handle it strictly on the business's instruction. Identifying the Article 9(2) condition is that business's job — commonly Article 9(2)(a) explicit consent, or Article 9(2)(h) health or social care together with the further condition at paragraph 2 of Part 1 of Schedule 1 to the Data Protection Act 2018 — as is the matching Schedule 1 condition and any appropriate policy document the Act demands. The DPA says so in terms, and requires a business expecting such material to tell us before deployment, complete an impact assessment where Article 35 bites, and apply shortened retention with extra masking rules.

If sensitive material lands where it should not have — pasted into a ticket, emailed to ask@veronaai.co, or buried in a file that should never have been uploaded — tell us. We will find it, remove or mask it (on the controlling business's instruction where we are processor), confirm what was done, and look at whether the route that allowed it needs changing. Nothing submitted by mistake is ever put to use.

18. If you were the person on the other end

Read this part if you wrote to a shop, a clinic, a letting agent or a practice, and the reply came from an AI assistant. You never signed up to Verona AI and may not have heard of us until now.

18.1 Who decides what happens

The business you contacted is the controller; Verona AI is only its processor. That business chose to run an agent, defined what it does, and decides what becomes of the record. We supply the software and hold the material on their behalf under a contract that stops us using it for anything else. Their own privacy notice — normally linked from the page, email or profile where the agent runs — names them.

18.2 What we hold, and what never happens to it

What section 3.1 lists: your messages, the agent's replies, the route you came in on, any attachment, timings and connection details. It stays for as long as the business instructs, within the defaults in section 7.1, which is normally 12 months. It is never used to train a model, never used to market anything to you, never sold, never shared with other businesses on the platform, and never assembled into a profile.

18.3 Reaching a person, and what to keep out of a chat box

You can ask for a human at any point — “can I speak to someone” does it — and the conversation moves across to the business's staff. No justification is needed. Please keep card details, passwords, health information and identity documents out of an agent conversation; if some have already gone in, tell the business, or tell us and we will help get them removed (section 17).

18.4 Getting your rights exercised

1. Go to the business first. As controller they can act across all their records, not merely the portion sitting with us. Section 19 explains each right.
2. If you cannot identify or reach them, write to ask@veronaai.co with the approximate date, the channel, and the business name if you have it.
3. What follows. We route your request to the controlling business promptly, confirm to you that we have done so, and give them whatever technical help they need. Acting on it ourselves without their instruction would put us outside our instructions, so we do not — but if they go quiet, tell us and we will press them.
4. Identity. We ask for the least that lets us be confident the request is yours, and never demand identity documents where something simpler will do.

You are free to complain to the ICO about the controlling business whenever you like (section 20), and about us if you think we have stepped outside our processor role.

19. Your rights and the desk that answers them

These rights attach to personal data for which we are the controller. If yours reached us through one of our customers, the request belongs with that customer — see section 18.4, and we will help either way.

19.1 To be informed

You are entitled to know who is processing your data, why, on what footing, who receives it and for how long. This page discharges that duty, topped up by notices where collection happens. If anything here reads badly, ask and we will explain it.

19.2 Access

You can ask whether we hold personal data about you and receive a copy together with the supplementary information at Article 15 — purposes, categories, recipients, periods, source and your rights. In practice that means a structured export of your account data and correspondence, masked only where disclosure would expose someone else's personal data or privileged material. The first copy costs nothing; a reasonable fee may attach to further copies of the same information.

19.3 Rectification

Anything inaccurate can be put right, and anything half-recorded can be completed. Most account fields you can fix yourself in settings, which is faster. Where the data has already gone to a recipient we pass the correction on unless that proves impossible or disproportionate.

19.4 Erasure

You can ask us to erase data that is no longer necessary, where you withdraw the consent it rested on, where you object and nothing overrides that objection, or where processing was unlawful. The right is not unlimited: records the law obliges us to keep, such as the accounting entries in section 13, and material needed for a legal claim, may stay. A refusal comes with reasons. Section 21 sets out the route.

19.5 Restriction

You can ask us to hold data without acting on it while we check accuracy you have contested, while an objection is being considered, or where processing is unlawful but you would rather restrict than erase. You hear from us before any restriction is lifted.

19.6 Objection

Where legitimate interests are the ground, you can object on grounds relating to your particular situation, and we stop unless we can show compelling legitimate grounds that override your interests, or the processing is needed for legal claims. Direct marketing carries no balancing exercise at all: we stop, at once and for good.

19.7 Portability

Where processing rests on consent or contract and runs automatically, you can receive the data you gave us in a structured, commonly used, machine-readable form — JSON or CSV here — and ask us to send it to another controller where that is technically feasible.

19.8 Withdrawing consent

Where consent is the ground — a customer's opt-in to a defined model-improvement dataset (4.3), or a device permission — you can withdraw it whenever you like, as easily as you gave it. Withdrawal leaves earlier processing valid and stops anything further on that basis.

19.9 Automated decisions

Article 22 gives you the right not to be subject to a decision taken by automated means alone where it produces legal or similarly significant effects. No such decisions are made here (section 5.1), so the right has nothing to attach to at present. Were that to change you would gain the right to human intervention, to putting your view and to contesting the outcome, and this page would say so first.

19.10 Making a request

1. Send it to ask@veronaai.co, or by post to the registered office marked “Data protection request”. Particular wording and legal citation are unnecessary, though naming the right you want speeds things along.
2. Identity. Where we have genuine doubt we verify, asking for the least that settles it — usually a reply sent from the account address. Anything supplied for verification is destroyed once the check is done.
3. Timing. Our answer comes inside one month, counted from the request arriving or from the verification material arriving, whichever is later. Complex or numerous requests may take up to two further months, and you would hear from us inside the first month with the reason.
4. Cost and refusal. Exercising a right costs nothing. A reasonable cost-based fee, or a refusal, is possible only where a request is manifestly unfounded or excessive. If we cannot comply in whole or in part we say so within the same month, give reasons, and set out your route to the ICO and to a judicial remedy.
5. No penalty. Using a right never means a worse service, and never account closure except where you asked for erasure and the account cannot run without the data. Requests from a solicitor, a relative or another representative are actioned on suitable written authority.

20. Complaining to the ICO

Raise it with us first at ask@veronaai.co. We will look into it and come back with what we found, normally inside a month — usually the quickest route, and it gives us the chance to put something right. You may nonetheless go to the UK supervisory authority at any time, whether or not you have spoken to us:

Information Commissioner's Office (ICO)
Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF
Telephone: 0303 123 1113
Website: ico.org.uk

An effective remedy through the courts may also be open to you, as may compensation where an infringement has done you damage.

21. Closing your account and erasing the record

You can close your account and have your personal data deleted whenever you choose, from inside the app or by email.

• In the app: Settings, then Account, then Delete account. You are shown what goes and asked to confirm, after which deletion runs on its own.
• By email: write to ask@veronaai.co from the account address with “Account deletion request” in the subject line. This route works whether or not the app is still installed and whether or not you can sign in.

Deletion completes within 30 days of a verified request. Cleared from live systems immediately: account identity, profile and preferences; credentials and sessions; support correspondence not tied to a live issue; device tokens; and telemetry attached to your account. Encrypted backups are purged on their normal rotation of no more than 35 days, during which the product cannot read the data and nothing uses it.

Those remnants are isolated, cut to the minimum and used for nothing else. Where an employer created your account, deleting your named user removes you, while the business material your agents handled belongs to that employer as controller and is dealt with under section 7.1. Removing the app from a device closes nothing: it does not end the account, does not cancel a subscription and does not erase data — use the routes above, and your store's subscription settings to stop billing.

22. Cookies, product news and updates to this page

22.1 Cookies and local storage

The Cookie Policy carries the detail: what these technologies are, how PECR and the UK GDPR govern them, an itemised table of what this site places on a device, our position on analytics and advertising technology, and browser-by-browser controls. In short, this site limits itself to strictly necessary security entries, carries no analytics or advertising technology, and would ask for consent before anything non-essential appeared. Inside the apps and the signed-in platform the storage in section 9.2 applies, all of it strictly necessary and none of it used for tracking.

22.2 Hearing from us

Very little goes out: occasional notes, to people who asked for them, about the agents and the service. There are no advertising campaigns here, no bought lists, no open-tracking pixels in our email, and your address goes to nobody for their own marketing.

• Why you hear from us. Because you asked, by writing in or by arranging a working session. Under PECR regulation 22 that request is your consent; where you subscribe as a corporate subscriber the individual-subscriber protections do not formally apply, but we treat everyone alike and honour an objection immediately. The associated processing rests on Article 6(1)(f).
• Existing customers. Information about closely related products may go out under the soft opt-in at PECR regulation 22(3), with an opt-out in every message.
• Stopping it. Use the unsubscribe link, reply with “unsubscribe”, or write to ask@veronaai.co. It is actioned promptly and permanently, leaving only a suppression entry.
• Service messages are different. Notes about your account, your subscription, security, an incident or a material change to these documents cannot be unsubscribed from while the account exists.

22.3 Changes to this policy

• Versioning. Every release carries an effective date, a last-updated date and a version number at the head of this page. This is version 3.0, effective 5 August 2026.
• Small changes — clarifications, corrections, contact routes — take effect on publication with the dates moved on.
• Substantive changes — a purpose we did not have, a category we did not hold, a recipient we did not use, a different basis, a different period — get advance warning three ways: email to account holders and to anyone subscribed to our updates, an in-app notice, and a banner carried on this page for 30 days or more. Customers also get notice under the DPA, including the sub-processor window in section 11.1.
• Where consent is needed for a change, we ask for it. Carrying on using the service is not an answer to that question.
• Superseded versions are kept and sent on request, so you can see what moved and when.

This page is also revised before any app or capability ships whose data handling is not already described above.

22.4 Reaching us

For anything on this page — questions, rights requests, complaints, requests for the DPA or the sub-processor register, security reports:

VERONA AI LIMITED
Data Protection Lead

Email: ask@veronaai.co

Email lands with the accountable director on working days and is by far the fastest route. Post is checked less often, so where a deadline matters please send an email as well as a letter. Statutory clocks run from receipt whichever route you pick (section 19.10).

Published by VERONA AI LIMITED, Company No. NI738464. Version 3.0 — effective 5 August 2026.