Before a restaurant AI pilot starts, ask the vendor to explain what it will delete, when deletion will happen, who else holds a copy, and what evidence you will receive. Cover generated reports and backups as well as the files you upload. Put the answers and the request process in writing before anyone sends real restaurant data.
A useful answer identifies each data location and names any exceptions. “We delete your account” alone does not tell you whether an uploaded sales file, a vendor's support copy, or a generated forecast remains somewhere else. Decide which answers you can accept before the pilot creates a cleanup problem.
Map what enters the tool and what comes out
Start with a list of the information the pilot needs. An AI forecasting tool might ask for daily sales, staffing schedules, menu items, and notes about events. A tool that summarizes guest feedback might receive comments that contain names or contact details. Those are different datasets, with different reasons to limit their use.
For each item, record where it comes from, who sends it, and where the vendor says it goes. Include manual uploads, connected systems, chat prompts, generated reports, downloaded files, and support attachments. Ask whether the vendor uses any of the information to develop or train models, and what happens to those uses when you request deletion.
Map the restaurant's own copies too. A manager may export figures from a restaurant POS system, email a spreadsheet to a colleague, and upload a revised copy. Deleting the vendor's copy does not remove the email attachment or the file on the manager's laptop. Agree who owns cleanup on each side.
Ask the vendor to identify where data is processed and stored, including locations used by hosting providers, support teams, and other subprocessors. A subprocessor is another company the vendor uses to provide part of the service. You do not need to draw its entire technical network, but you do need to know which parties may receive the dataset and how a deletion request reaches them.
Use a small, labeled dataset first
For an initial evaluation, consider fictional or stripped-down records instead of guest details and complete sales histories. Ask whether the tool can answer your buying questions with that smaller set. Removing names does not automatically make every record unidentifiable, so review unusual notes and combinations of fields before upload.
Keep a simple upload register: file name, date, uploader, contents, destination, and pilot purpose. Note subsequent versions separately. This makes the deletion request specific enough for both sides to act on.
Set the deletion terms before the pilot
Ask for the trigger and the clock. Does deletion start when the pilot expires, when you close the account, or only when an authorized person submits a request? How long does the vendor need to remove active copies, and what is the separate schedule for backups? Get dates or time periods in the agreement rather than relying on an informal promise.
Then ask what the request covers. A useful checklist includes the original uploads, revised files, prompts, generated outputs stored by the vendor, logs, support copies, and copies held by subprocessors. Ask whether information used in model training or derived datasets can be removed, and what the vendor can and cannot do. Do not assume that deleting a visible report reverses every downstream use of its source data.
Some records may remain for a stated purpose or until a backup cycle ends. Ask the vendor to list each exception, its purpose, the expected retention period, who can access the remaining data, and when it will be deleted or reviewed. Ask whether backup copies can be accessed or restored during that period and how deletion is handled if a backup is restored.
Also establish how to submit a request and escalate a missed deadline. Who may authorize it? Will the vendor notify subprocessors, or must you contact any of them separately? If the restaurant closes the account, will someone still be available to answer questions? Have a qualified adviser review contract terms and retention obligations where needed.
Compare the practical choices
- Proceed with real data: Use this when the pilot requires it and the written scope, deletion schedule, exceptions, and evidence meet your requirements.
- Limit the dataset: Use fictional or reduced records when they are enough to judge the workflow, or when the deletion terms are not strong enough for the full dataset.
- Choose another approach: Decline or postpone the pilot if the vendor cannot explain where data goes or what happens after the pilot, and you cannot run a meaningful evaluation with less sensitive information.
These choices involve more than the subscription quote. Ask about any setup, export, deletion, support, or early termination charges, including charges for special requests. Compare written operational quotes on the same scope. Do not treat a deletion fee alone as the full cost of a pilot.
Use a deletion worksheet for the decision
The following is a hypothetical example. A restaurant wants to evaluate a demand-planning tool using fictional daily sales and staffing figures. Its owner will proceed only with the fictional dataset until the vendor provides an acceptable written deletion schedule and explains its backup and model-use terms. No vendor response or deletion has occurred in this example.
The worksheet turns that decision into specific requests. The last column is the restaurant's acceptance condition, not a claim that the vendor can meet it.
| Item | Ask the vendor | Restaurant action | Acceptance condition |
|---|---|---|---|
| Fictional sales file | Where is each uploaded version stored and processed? | Log file names and upload dates. | Vendor identifies active storage and subprocessors in writing. |
| Generated forecast | Is the output retained after account closure? | Record any copies downloaded by staff. | Vendor specifies the output deletion process and timeline. |
| Backups and logs | What remains, why, and for how long? | Compare exceptions with the restaurant's policy. | Each exception has a purpose and a deletion or review date. |
| Model use | Is pilot data used for training or derived datasets? Can it be removed? | Keep real records out until terms are acceptable. | Vendor states permitted uses and removal limits in writing. |
If the vendor's answers satisfy the conditions, the owner can separately decide whether the pilot is useful enough to continue. If they do not, the owner can keep the evaluation fictional, negotiate different terms, or stop. The worksheet should travel with the pilot agreement so the person ending the trial knows what to request.
Request evidence and run an acceptance check
Before the pilot begins, agree on the evidence the vendor will provide after a deletion request. Ask for a written confirmation that identifies the dataset and request date, describes the systems and subprocessors covered, gives the completion date for active copies, and lists anything retained with its reason and expected end date. Ask who can answer follow-up questions.
A practical acceptance check can use the fictional file from the worksheet. During a simulated check, first label the file and record where it is uploaded. Generate a fictional report, note its name, and submit a deletion request through the agreed channel. This is a data-handling exercise: it should not trigger a real card payment, guest message, or courier dispatch.
When the vendor responds, compare its confirmation with the worksheet. Does it name the uploaded file and generated report? Does it address active copies, subprocessors, backups, logs, and model use? Are exceptions and dates specific enough to compare with the agreement? Separately, check whether the file and report remain visible in the restaurant's account, without assuming that invisibility proves every backend copy is gone.
Mark the check accepted only if the agreed response is complete and any retained copies fit the agreed exceptions. If a detail is missing, ask for a corrected response and a deadline; do not mark an unresolved exception as deleted. A confirmation is evidence of the vendor's response, not independent proof of every technical action. Decide in advance whether that evidence is sufficient for the sensitivity of the data you intend to use.
A live service pilot is different. If you later use actual restaurant records, apply the agreed safeguards and deletion process to those records separately. The fictional check does not establish that every live-data request will be handled correctly.
Keep the records your restaurant needs
Vendor deletion and restaurant retention are separate decisions. Before asking for removal, identify reports or source records your restaurant needs to keep under its own policy. Confirm how you will retrieve them, who will store them, and whether the vendor's export contains the fields and format you need. Do not assume an account-closure screen provides a complete archive.
For example, a forecast generated during a pilot may help explain a scheduling decision, while the underlying sales records may belong in the restaurant's normal recordkeeping system. Decide whether either copy is needed and for how long. Review applicable obligations with a qualified adviser rather than treating the vendor's retention schedule as your own policy.
After any necessary export, check the restaurant's local cleanup list: downloads, shared folders, email attachments, and staff devices. Keep a record of the request and the vendor's response according to your policy. That record helps a future manager understand what was deleted and what exceptions remained without keeping unnecessary pilot data indefinitely.
As a next step, list the workflows and records you want a pilot to use, then compare your management requirements with Fleksa's restaurant management software. For a separate look at how shift figures may be organized before an evaluation, see the guide to comparing labor hours with sales by shift.
Frequently asked questions
Should I request deletion before or after a pilot?
Agree on the process before the pilot, then submit the request at the agreed trigger. If you may need an export, arrange it before closing the account.
Does closing an AI account delete restaurant data?
Do not assume it does. Ask whether closure starts deletion, which data and subprocessors are covered, and what remains in backups or other exceptions.
What evidence should an owner request?
Request a written confirmation naming the dataset, actions completed, dates, subprocessors covered, and any retained copies and their expected deletion or review dates.
