Skip to content

Legal

AI Disclosure

What ONE Travel OS sends to artificial intelligence, what it does not, and what would have to be true before that changes.

Applies to
Anyone, including agencies, advisors, and the travelers they serve
Effective

Software that holds passport numbers, a family’s travel plans and an advisor’s correspondence ought to be able to say plainly whether a machine-learning model reads any of it.

This is that answer. It is short enough to read and specific enough to check.

1. One thing of yours goes to a model, and here is exactly what

Where document parsing is enabled, the documents given to ONE Travel OS to read are sent to an outside document-parsing service, which uses machine learning to turn them into structured records. There are two such services: Reducto, and Google Cloud (Vertex AI), which reads them with Google’s Gemini models. Nothing else of yours goes to any model.

Which documents those are, which service reads which, and who may send one, is set out in the DPA sections 2, 3 and 10. That is the authoritative list rather than any sentence on this page. One thing is worth stating here because it is a separate decision rather than a detail of that list: a traveler’s passport can be read (at the traveler’s own request, or by their agency with the traveler’s agreement) and that is governed by its own switch, off until an agency turns it on, which enabling document parsing does not do.

This page previously said no such integration existed. It does now, and this section changed on the day it went live rather than afterwards.

Read section 3 before relying on this one. The two services are not under the same terms. Reducto’s terms on the plan we are on permit them to use submitted documents to train and improve their own models and services, and they do not offer an agreement barring that at our level. Google’s terms for Vertex AI bar it from training on what we send. That is disclosed in section 3, in the DPA section 3, and in what section 5 of this page no longer claims.

And nothing goes to either by itself. A document reaches a parsing service because a person deliberately sent it, never because a schedule ran or a mailbox was swept. The DPA section 2 names the acts that count as sending one. Check that list rather than this sentence. It has grown once already, and a page that copies it is a page that goes stale without anybody noticing.

Concretely, none of this happens:

  • No model is given your households, travelers, trips, bookings, itineraries, notes or correspondence as records. Only a document somebody handed to a parser is sent, and only that document. Where a traveler’s passport is read, that document is of course about a traveler, and what stays true is that the scan chosen to be read is all that goes, not the record we hold about them.
  • No model reads a mailbox an advisor has connected.
  • Nothing writes text for you. There is no drafted email, no generated itinerary, no summarized thread, no suggested reply.
  • Nothing scores, ranks or profiles a person, and no decision about a traveler is made automatically. A parsed document produces a draft that a person checks and accepts; nothing becomes a booking or a payment on a machine’s say-so.
  • There is no assistant, no chatbot and no prompt box anywhere in ONE Travel OS.
  • We do not train models on anything you or your households have put in, and we do not give it to anyone else to do so, with the single exception in section 3, which is the documents sent to Reducto to be parsed.

The Privacy Policy says we do not use your data to train machine-learning models, and that we do not use an agency’s data to build, train or improve a product, ours or anyone’s. Both remain true of us. Neither is a statement about what Reducto is permitted to do with a document we hand it; that is section 3.

Two AI services are disclosed, and each was disclosed before it could be reached. The Data Processing Addendum names every outside service that touches agency data, and it names both; each was added to that table while the code that could reach it was still unmerged. They apply only where document parsing is enabled for you. Section 3 says where the work stands; section 4 is what governs it.

That table is the authoritative list, not this page. Check it rather than this sentence.

2. Automation that is not AI

Some of what ONE Travel OS does happens without anyone pressing a button. None of it is a model, and the distinction is worth drawing, because “automated” and “AI” have started to be used as if they were the same word.

What it does How it actually works
Suggests which booking a commission-statement line belongs to Fixed rules. Confirmation number is the strong match; names are compared with case and punctuation stripped out; how close the amount is breaks the tie. Each suggestion shows its reasons and waits for a person to accept it
Refuses payment card numbers in notes, outgoing mail, and the text of an uploaded file A digit pattern, an issuer prefix and the Luhn checksum. It reads text, so it finds nothing in a photograph
Tells a person from a script on public forms Cloudflare Turnstile, a bot check. Not an analytics product, and it does not profile you
Sends deadline digests and reminders A schedule and a comparison of dates

These are ordinary code. The same input gives the same answer every time, the rules were written by hand and can be read, and none of them learns anything from your data.

3. The document parsers, and the promise we could not get from one of them

ONE Travel OS uses outside document-parsing services to read the PDFs, spreadsheets and scans that arrive as commission statements and supplier confirmations, so that they stop being re-keyed by hand, and to read a traveler’s passport rather than having the details typed in. Document parsing is off for an agency until one of that agency’s admins switches it on, and until then that agency sends no parsing service anything at all.

There are two services, Reducto and Google Cloud (Vertex AI), and which one reads a given kind of document is our choice, made for the whole of ONE Travel OS rather than agency by agency. The DPA sections 3 and 10 say what each may be sent.

Passports are the second switch, not part of the first, and they never go to Reducto to be read. They are read only by Google Cloud (Vertex AI), and every emailed document, and every document bound for Reducto, is first checked by it for what kind of document it is, so that one sent anyway is recognized, refused and not kept. See the bullets below and the DPA section 3.

The part you should read twice. We are on Reducto’s Standard plan. Their terms grant them a license to use what is submitted “to develop and improve the Services, to develop new offerings or features, and for our other business purposes”, and their zero-retention and no-training protections start at a higher tier. We asked whether they would sign a data processing agreement barring training and service improvement on documents we submit. They do not offer one at our level.

So we cannot tell you that this vendor is barred from learning from your documents, and we are not going to imply it. Section 5 of this page used to promise it and no longer does.

Google Cloud (Vertex AI) is different, and the difference is in writing. Google’s terms for the service bar it from using what we send to train or fine-tune its models without our permission, and under them it acts as our processor. It also keeps nothing. Google’s automated abuse checks could store a request they flag, and Google lifts that for a project only on approval; it approved ours on 29 September 2026. The DPA section 3 says what that rests on. Nothing goes to Google Cloud (Vertex AI) until it is configured for ONE Travel OS and an agency has switched document parsing on.

What is true, and what bounds it:

  • Only documents go. The statement, confirmation or identity document handed to a parser, and nothing else. No household list, no trip history, no mailbox, no database access. When someone emails a forwarding address with nothing readable attached, we send the email’s text as the document, since a booking email can carry its itinerary there. Any note they typed above a forwarded booking goes with it.
  • Only a fixed list of fields comes back, and which list depends on the kind of document; the DPA section 3 sets them out. A document’s other contents are not returned to us, which limits what we hold, not what a parsing service does.
  • Never a card number we can read. A document’s own text is read for card numbers when it arrives, and what a parser sends back is read again; one found at either point is refused outright, not imported, and not kept. A card in a photograph, or in a scan with no text in it, leaves nothing for that reading to find.
  • Off unless enabled, and passports need a second yes. Document parsing is off for an agency until one of its admins switches it on, under “Document parsing” in Agency settings. Identity documents are a separate switch beside it, also off, and turning the first on does not turn the second on. An agency that agreed to send us commercial paperwork has not thereby agreed to send us its travelers’ passports. While a switch is off there is no upload control and no forwarding address anywhere, including in households’ portals, and a document that arrives regardless is refused, sent nowhere and not kept.
  • A traveler is never made to. Where the second switch is on, a traveler is offered the reading and told where the scan goes, and their agency may send one only after confirming that the traveler agreed; who confirmed it, and when, is recorded. Declining costs a traveler nothing but typing the details themselves, and nothing else they get is worse for it.
  • Nothing goes without somebody sending it. One document at a time, on a deliberate act named in the DPA section 2. Nothing is swept out of a mailbox, nothing runs on a schedule, and nothing is sent in bulk.
  • A person accepts every result. Parsing produces a draft on a review screen. Nothing becomes a booking, a commission line, a payment or a traveler’s passport details until somebody checks it.
  • For Reducto, no retention period is published for our plan. Reducto’s stated expiry applies to the higher tier. We do not know how long a document submitted to Reducto is kept, and we would rather say that than quote a figure that is not ours.

If any of this is not acceptable to you, do not enable document parsing, and tell us. The DPA section 10 notice provision exists for exactly this kind of objection.

4. What must be true before any AI touches your data

These conditions apply to the parsing work above and to anything else we might add later.

You are told first, and you can object. An AI service handling your data would be a subprocessor, and the DPA already binds us on those: it is added to the table by name, you get at least thirty days’ notice before it handles anything, and if you object on privacy grounds and we cannot resolve it, you may end the affected service without penalty. That right exists today; nothing has to be added for you to use it.

It is off until it is turned on. Like every optional service in the DPA table, it would ship inert. An agency that does nothing has nothing sent.

We train nothing on your data, and one vendor is not under that promise. The Data Processing Addendum bars us from using your data to develop, train, benchmark or improve any model, and bars us from handing it to anyone else so that they can, with one exception it names outright: Reducto, one of the two document-parsing services in section 3 above. What each outside service is bound to is set out there, service by service, and those undertakings are not uniform. Read it there rather than taking any of it from this page.

It sees a document, not your database. A parsing service would receive the file handed to it and nothing else. No household list, no trip history, no mailbox.

A person decides. Anything a model produced would be a suggestion until somebody accepted it. Nothing would become a booking, a payment or a record about a traveler without a human. A wrong answer is then wrong on a review screen rather than in your books.

The protections already in place still apply. Card numbers are still refused wherever they can be read, sensitive fields are still encrypted individually, and the audit trail still records what changed and who changed it.

This page changes before the feature does, not after. Reducto was named here and on the DPA table before any code existed that could reach it, and so was Google Cloud (Vertex AI); this page was rewritten again on the day parsing went live, not in the week after. The order has been disclosure first throughout, including for the part we would rather not have had to write down.

5. What we will not do

Not “have not yet”: will not. If any of these ever changes, you will hear about it under section 4 before it happens, and not from this list quietly getting shorter.

  • Train any model on agency, household or traveler data ourselves, or hand your data to anyone else for that purpose beyond the one disclosed in section 3.
  • Let a model decide something about a person (whether to take them on, what to charge them, what they are worth) without a person deciding it.
  • Put machine-written text in front of your households as though a human wrote it.
  • Send your data to a model to find out whether the result would be useful.
  • Widen what goes to a parsing vendor beyond the document you asked us to read.

One line used to be on this list and has been taken off it: “Let a vendor use what it sees for its own purposes.” We could not keep it. Reducto’s terms on our plan permit exactly that for documents submitted to them, and they do not offer an agreement barring it at our level; see section 3. Removing the promise is the honest response; leaving it up while it was untrue was not an option, and neither was implying we had obtained something we had not.

If we later obtain that undertaking in writing, the line comes back and the date at the top changes with it.

6. Changes

When this page changes we update the date at the top and keep the previous version. If we add anything that sends your data to a model, account holders are told directly before it takes effect, on the notice period in section 4.

Ask us for the version in force on a particular date and we will show you.

Effective What changed
2 October 2026 We can now read a booking from the email itself. When an email to a forwarding address has nothing readable attached, we send its text to a parser as the document, and section 3 says so. That text meets every rule an attachment meets: we send it only for a sender the agency already knows, we refuse it if it shows a card number, and we refuse an identity document and keep none of it. We also read any note typed above a forwarded booking
29 September 2026 Section 3 now says Google Cloud (Vertex AI) keeps nothing, where it used to say we would not claim that. Google approved an exemption from its abuse-monitoring logging for both the projects ONE Travel OS uses on 29 September 2026, and the DPA section 3 carries what the promise rests on. Nothing changed about what is sent, who reads it, or what it may be used for
18 September 2026 (the screen) Section 3 no longer points at a way an emailed passport could reach Reducto, because there is none: every emailed document, and every document bound for Reducto, is first checked by Google Cloud (Vertex AI) for what kind of document it is, and an identity document is refused and not kept
18 September 2026 A second document-parsing service, Google Cloud (Vertex AI), reading documents with Google’s Gemini models, is named in sections 1 and 3 the same day it was added to the DPA table and before any code can reach it. Unlike Reducto, Google’s terms for the service bar it from training on what we send, and section 3 says so, along with what we do not claim for it, that nothing is kept. Passports now go only to Google Cloud (Vertex AI) and never to Reducto to be read, and an agency may now also ask for one to be read, after confirming the traveler agreed, behind the same second switch as the traveler’s own request. Which service reads statements and confirmations is our choice for the whole of ONE Travel OS; this page names both and defers to the DPA for which may be sent what
7 September 2026 A traveler may now ask us to read their own passport rather than typing it in, so a new kind of document can reach the parser, the first that is a person’s identity rather than commercial paperwork, and the first sent by somebody who is not at the agency. It has its own switch, off, and turning document parsing on does not turn it on: an agency that agreed to send us statements has not agreed to send us its travelers’ passports. A traveler is offered the reading, never made to take it, and declining costs them nothing but typing. Under section 6 this is “something that sends your data to a model”, so account holders are told directly and the section 4 thirty-day notice runs before the switch can be offered. The default-off design does not stand in for that notice, because section 4 requires both. Sections 1 and 3 also stop restating the DPA’s list of what may be sent and who may send it, and defer to it instead: that list has now grown once, and a copy of it here is a copy that goes stale unnoticed
3 September 2026 Says “train” where it previously said only “improve”: Reducto’s license is broad enough to cover training, and their no-training undertaking is a feature of a higher plan, so this page now states that plainly in sections 1 and 3. Section 3 also corrects “It is live”: parsing is built and available, and off for an agency until one of its admins switches it on, which is a control that did not exist when that sentence was written. New in sections 1 and 3: nothing reaches Reducto except on a person’s deliberate act, never a schedule or a mailbox sweep
2 September 2026 Document parsing went live. Section 1 no longer says nothing goes to a model; it says what does. Section 3 records that Reducto will not sign a data processing agreement on our plan, so training and service improvement on submitted documents is permitted to them. Section 5 lost the promise “let a vendor use what it sees for its own purposes”, which we could no longer keep. Sections 1 and 3 of the same day, earlier, had said the code was present and inert
1 September 2026 First version

7. Questions

Write to onetravelos@taclinetech.com and say what you would like to know. If the answer belongs on this page, we would rather add it than send it once.

TacLine LLC 418 Broadway STE R, Albany, NY 12207