This policy explains what personal data Infomatics, Inc. handles, in which role it handles it, and what you can do about it. It covers the infomatics.ai website, the Infomatics platform, the Kopilot mobile app, and the people whose data moves through them, including drivers and other individuals who are not our customers.
This policy applies to the website at infomatics.ai, to the Infomatics platform, to the Kopilot driver and security-escort app, and to sales and support interactions with us. It covers three groups of people: visitors to our website, employees of our business customers who hold platform accounts, and individuals whose personal data appears inside a customer's account because that customer or one of their partners put it there. The third group is the largest, and most of those people never signed up with us. Sections 2 and 9 explain what that means in practice.
Infomatics sells to businesses. Our customers are freight brokers, 3PLs, shippers, carriers, enterprise supply chains, and government and defense logistics operations. We do not sell a consumer product. Apart from our website forms and the Kopilot app used by drivers and security escorts on a customer's instruction, we do not collect personal data directly from individuals. Section 9 covers Kopilot and the people whose data it collects.
This policy sits alongside two other documents. Our Terms of Service govern use of the platform. Our Security page describes security practice in full. Where a signed customer agreement or Data Processing Addendum (DPA) covers the same subject as this policy, that agreement governs for the data a customer routes through the platform. This policy is not a substitute for it and does not modify it.
Infomatics has two distinct roles, and nearly every question about rights, retention, and disclosure depends on which one applies. For the operational data a customer connects or sends to the platform, Infomatics is a processor (a service provider under US state law). The customer decides what data enters the platform, why it is there, how long it stays, and who may see it. We act on the customer's documented instructions and on the automation the customer configures.
For our own business data, Infomatics is a controller. That includes website visitors, people who fill in the contact or demo form, sales and marketing contacts, the administrative and billing records behind a customer account, support correspondence, and our own security and audit logs. In that role we decide the purposes and means, and this policy is the notice for it.
The distinction has a practical consequence. If your personal data is in a customer's account because you drive for a carrier, work for a broker, or signed a delivery, Infomatics is not the party that decides how that data is used, and we cannot delete or correct it on our own authority. Direct that request to the company whose account holds it. Section 13 explains what we can and cannot do to help you identify that company.
Infomatics sits above a customer's existing systems and reconciles data from them. The categories below are what the platform necessarily touches when it does that work. Customers choose which of these to connect; the list describes the full surface, not a minimum.
Some of this is personal data about identifiable people, and some of it is sensitive by nature. Precise location history, duty status, and identity photos say a great deal about a person's movements and working hours. We treat precise geolocation as sensitive personal information where applicable law defines it that way, and we apply the same controls to it whether or not a given law applies.
Free-text fields and OCR are the two places where unexpected data arrives. An OCR'd bill of lading or a forwarded email can contain personal details nobody intended to send us. We do not ask for special categories of data (health, biometric identifiers used for identification, government ID numbers beyond what freight documents ordinarily carry), and customers should not route them through the platform without a written agreement covering them. Anything that does arrive is held under the same access controls and retention rules as the rest of the tenant.
Separately from freight data, we hold records about the people at our customers who use the platform. That includes name, work email address, work phone number, job role, tenant and permission assignments, and the SMS number used for escalations. We also hold authentication records: sign-in events, multi-factor enrollment, IP address, browser and device information, and session activity.
The platform keeps an audit log of user actions, because an intelligence layer that acts on shipments has to be able to show who approved what, who changed a plan, and which action was taken by an agent rather than a person. That log includes the user identity attached to each action. It is written for the customer's benefit and is visible to the customer's administrators.
Our role here is split, and we state it plainly. For account administration, authentication, billing, security monitoring, and support, we act as a controller, because we determine how those functions work. For the same user records as they appear inside the customer's operational data and audit trail, we act as a processor for that customer. Both statements are true at once. We do not use customer user records for our own marketing.
If you visit infomatics.ai we collect standard request data: IP address, approximate location derived from it, browser and device type, referring page, and pages viewed. If you submit the contact form we collect what you type into it, which is typically your name, email address, shipment volume, and a description of your operation. If you email contact@infomatics.ai or sales@infomatics.ai we keep the correspondence and the contact details in it.
We use this to answer inquiries, to prepare a walkthrough relevant to your operation, and to run ordinary business-to-business marketing to people who have shown interest. Where consent is required for marketing email, we ask for it, and every marketing message includes a way to stop receiving them. We do not use this data to build advertising profiles of individuals.
We also keep support and incident correspondence, which sometimes contains screenshots or exported records from a customer's tenant. Support material of that kind is treated as customer data under section 3, not as our own marketing data.
Very little of the operational data we hold is typed into our platform by hand. It arrives from systems a customer already runs, from equipment already in their supply chain, and from people in the field.
The list below is a description of channels, not a claim that every customer connects all of them. Each connection is authorized by the customer, using credentials or tokens the customer supplies or approves, and is scoped to the data that customer's workflows need. When we connect to a partner system on a customer's instruction, we read what that customer's account there exposes to us.
The important consequence: data about people reaches us through their employer, their carrier, or their broker rather than from them directly. A driver's phone number typically arrives in a load tender from a TMS. A driver's location typically arrives from an ELD or tracker the carrier already operates, or from the Kopilot app on the driver's phone. We did not ask that person for it, which is why section 9 exists.
Customer data is used to operate the service the customer bought and for nothing else. Concretely: to ingest and reconcile shipment data across connected systems; to let agents monitor shipments against plan; to create orders from inbound email; to plan and route loads; to coordinate with carriers and partners; to detect exceptions; and to escalate to a named human by SMS when a decision requires judgment. It is also used to produce the evidence record attached to a shipment, to support the customer when something goes wrong, to keep the service secure, and to meet legal obligations.
Our own controller data is used to run the business: to respond to inquiries, to administer accounts and billing, to provide support, to send business-to-business marketing where permitted, to measure how the website performs, to detect and investigate abuse, and to comply with law. Our legal bases in the EEA and UK are performance of a contract, our legitimate interests in operating and securing the service and in ordinary business marketing, consent where we ask for it, and compliance with legal obligations.
We do not sell customer data and we do not use it for advertising.
The platform uses AI models to read documents, extract order details from email, classify exceptions, draft messages to carriers, and decide when to escalate. Some of that inference runs on models operated by third-party providers under contract with us. When it does, the content required for that specific task is sent to the provider, processed, and returned. Where we use third-party model providers, we require contractual terms that prohibit training on data we submit. Customers can ask us which model providers are used for their account and on what terms.
One question governs the rest of this section: whether any part of the platform is derived from data across more than one customer. That includes shared or general-purpose model training, network-level features such as corridor risk signals, benchmarking, and the aggregated and de-identified data that the Terms of Service permit us to create from platform usage and customer data. The answer is the following, and it is the operative statement of our position. Customer Data is not used to train or fine-tune models that serve any other customer, and derived intelligence, including network and lane intelligence built from shipment history, stays within the tenant that produced it. Within that limit, we may create aggregated and de-identified data from platform usage and customer data; the extent of that permission, and the form the data must take, is set by the aggregated-data grant in section 10 of the Terms of Service and by the customer agreement, and customers can ask us in writing how it applies to their account.
Our engineers can access customer data when it is necessary to operate the service, investigate an incident, or resolve a support request, under the controls described in section 12. That access is not a route to a labeling or training pipeline: customer content viewed for support is not turned into training data.
Agents act autonomously within the rules a customer configures, and the product is designed to escalate to a person rather than to make decisions with legal or similarly significant effects on individuals. Where a customer configures the platform to influence such decisions about their own workers or contractors, that customer is the controller of that decision.
Drivers and security escorts carry the most sensitive data in the platform, and they are almost never the party that bought it. A driver's record can include their name, mobile phone number, duty status, assignment history, photographs they upload, their signature, and a precise location trail sampled continuously while a load is moving. A trail like that reveals routes, rest stops, home base, and working hours. We treat it as sensitive, and we do not use it for any purpose beyond running the customer's shipment workflows.
The driver usually works for a carrier, and that carrier works with our customer. The customer, and in some cases the carrier, is the controller of that driver's data and is responsible for telling the driver what is collected and on what basis. Infomatics is the processor. We cannot lawfully grant or refuse a driver's request on our own; we route it to the controller and support them in answering it. Section 13 explains how to make the request and what we can do with it.
The platform sends text messages to drivers to confirm status, request evidence, or resolve an exception, and to customer staff when an agent escalates for judgment. Phone numbers come from the customer's own systems or from Kopilot registration, never from a purchased list. Message content is limited to what the workflow requires, and message and data rates may apply on the recipient's plan. A recipient who no longer wants these messages should tell the carrier or dispatcher who assigned the load, since the phone number and the workflow behind the message belong to the customer's account.
Kopilot collects location, photos, signatures, and escort position and status directly from the driver's device. Device permissions are requested in the app, and a driver can withdraw them in the operating system, though doing so will stop parts of the app from working and the driver should tell their dispatcher first. Retention of this data, and what happens to it when a driver leaves a carrier, is covered in section 11.
We use subprocessors to run the service. The categories are cloud hosting and managed data services, model inference for the AI agents, OCR for document text extraction, SMS delivery for human escalation, transactional email, error monitoring, and product analytics. This is the same list published on the Security page. Subprocessors are bound by written terms that limit them to our instructions and require confidentiality and appropriate security. The platform runs on managed cloud infrastructure operated by a major provider; Infomatics does not operate its own data centers. The current subprocessor list, naming each subprocessor and where it processes data, is available to customers on request, and the notice and objection process for adding a subprocessor is set out in the customer agreement.
Integration partners are a different thing, and conflating the two would misdescribe how data actually flows. When a customer connects Turvo, McLeod, Aljex, Tai, Revenova, 3PL Systems, Highway, Truckstop RMIS, MyCarrierPackets, Front, Outlook, Slack, Microsoft Teams, RingCentral, Gmail, DAT, Truckstop, Transfix, Sonar, AVRL, Tabi, Bitfreighter, Triumph/Greenscreens, Cleo, Orderful, or Atadex, they are directing us to exchange data with their own account at that provider. Data sent to those systems is governed by the customer's own agreement with them, not by ours. We do not use those connections to obtain data for our own purposes.
We may also disclose data when required by law or valid legal process, when necessary to establish or defend legal claims, to protect the rights and safety of people or property, and to a successor in connection with a merger, acquisition, or sale of assets. Where a legal demand covers a customer's data and we are permitted to tell them, we will, so the customer can respond as the controller.
Freight crosses borders, so its data does too. A single international load produces location pings in more than one country before it is delivered. Personal data may be transferred to and processed in countries other than where it was collected, including the United States. Where personal data is transferred out of the EEA, the United Kingdom or Switzerland, the processing locations and the transfer terms that apply are set out in the customer agreement and its Data Processing Addendum, and customers can ask us which of those terms apply to their account.
Customer data is retained for as long as the customer's account is active and according to the retention settings and contract terms that customer has agreed. Customers control deletion of records inside their tenant. Some evidence, such as proof of delivery and the custody chain behind a claim, is deliberately kept longer than the shipment itself because it exists to settle disputes and satisfy audits; the customer decides that period, not us.
Driver and escort data follows the same rule, and this is where a driver should look for it. Location history, photos, signatures, and other evidence captured in Kopilot are retained under the retention the customer configures and the terms of that customer's agreement. Evidence media attached to a claim or a custody dispute is commonly kept longer than the load itself, at the customer's direction. A driver who leaves a carrier should direct a deletion request to that carrier or to the customer whose account holds the record, as described in sections 9 and 13; we act on the controller's instruction.
On termination, we return or delete customer data according to the customer agreement. Deletion takes effect in active systems first, and copies of deleted records may persist in backups for a period after that, so deletion is not instantaneous everywhere at once. The return and deletion window after termination, and the treatment and retention of backups, are those set out in the customer agreement.
For data where we are the controller, we keep account and billing records for as long as the relationship lasts and afterwards for the period applicable law requires, marketing contact records until the contact opts out or goes cold, and website analytics and security logs for a defined operational period.
We may hold aggregated or de-identified data that no longer identifies anyone, for example volume statistics or model evaluation metrics, and the Terms of Service grant us a right to create and use data of that kind to operate, secure, benchmark and improve the platform. That right operates under the limit stated in section 8: Customer Data is not used to train or fine-tune models that serve any other customer, and derived intelligence, including network and lane intelligence built from shipment history, stays within the tenant that produced it. Within that limit, the extent of the grant is set by section 10 of the Terms of Service and by the customer agreement, and customers can ask us in writing how it applies to their account. Where we hold de-identified data, we maintain it in de-identified form and do not attempt to re-identify it.
Security practice is described in full on our Security page, and this section states only the parts that bear directly on personal data. We encrypt data in transit and at rest. The platform is multi-tenant, and authorization is designed to be enforced so that one customer's data is not reachable from another's session. We require multi-factor authentication for internal elevation, and access is logged. Integration credentials and API tokens are held in a dedicated secret store rather than in application databases, and the design intent is that key material is held separately from the application database.
Infomatics staff do not hold standing access to customer production data. Our practice is that access is requested against a support ticket or a declared incident, approved by someone other than the requester, scoped to the single tenant concerned, granted for a limited window, and set to expire automatically; we require multi-factor authentication for elevation, and elevation is available only to a small named group. A separate break-glass path exists for emergencies; it is designed as a distinct, named path that is time-bound and emits an audit record. Access is intended to be attributable to a named individual.
We review vendors before they process customer data, run a documented incident-response process, and maintain change controls over the code that touches customer records. Where a security incident affects a customer's data, we notify that customer so they can meet their own obligations as controller.
A current list of attestations and completed security questionnaires is available to customers and prospects on request. Testing cadence, breach-notification and availability commitments are those set out in the customer agreement.
No system is completely secure. If you believe you have found a vulnerability or that an account has been compromised, contact us at contact@infomatics.ai. Testing against the platform requires prior written authorization from Infomatics; see the Acceptable Use section of the Terms of Service.
Depending on where you live, you may have the right to access the personal data held about you, to correct it, to delete it, to obtain a portable copy, to object to or restrict certain processing, to withdraw consent, to opt out of the sale or sharing of personal data and of targeted advertising, to limit the use of sensitive personal information, and to appeal a refusal. Under the GDPR and UK GDPR you may also complain to your supervisory authority. We do not discriminate against anyone for exercising these rights.
Where to send the request depends on the role described in section 2. If your data is in the platform because of a business relationship with one of our customers, which is the case for drivers, escorts, carrier staff, broker contacts, and consignee contacts, send the request to that company. They are the controller.
If you do not know which company holds your data, tell us the carrier you drive for, the approximate dates, and any load or reference numbers. Where we can identify the customer from that information without a general search of customer accounts, we will forward your request to them and assist them in fulfilling it. Otherwise we will tell you what information would let the carrier or broker identify the record. Any search inside a customer's tenant is performed under that customer's instruction; we do not search across customer accounts on our own initiative, and our access controls are designed to prevent it (see section 12).
If you are a website visitor, a marketing or sales contact, or an account holder asking about your own account and authentication records, write to contact@infomatics.ai and we will handle the request ourselves as controller. We will verify your identity before acting, which for account holders normally means responding from the address on file. We respond within the period the applicable law requires and will tell you if we need an extension.
Which privacy law applies to a given request depends on where you live and on the role in which we hold your data. Write to contact@infomatics.ai and we will tell you how we are handling your request and, where we are not the controller, who is.
Platform accounts and Kopilot accounts are for adults. The minimum age for any user of the Infomatics platform or of Kopilot is 18. The Terms of Service state the same requirement. Kopilot is issued to working commercial drivers and security escorts through a customer's operation. We do not market it to the public and it is not available for personal use.
The website is not directed to children, and we do not knowingly collect personal data from anyone under the age of 16 through it. This is a business-to-business product sold to logistics operators; there is no consumer sign-up and no feature intended for personal or family use.
If we learn that we hold personal data from a child, we will delete it. If you believe a child's data has reached the platform, contact us at contact@infomatics.ai and, where the data sits inside a customer's account, we will notify that customer as controller so it can be removed.
We update this policy when the product, our subprocessors, or the applicable law changes. The current version is always posted here with its effective date. Where a change materially affects how we handle customer data, we notify customers through the account or by email in line with the customer agreement, and where the law requires consent for a change we will ask for it rather than assume it. The notice period for material changes is the one set out in the customer agreement.
For privacy questions, rights requests about data we control, and security reports, write to contact@infomatics.ai. For commercial and contractual questions, including the Data Processing Addendum (DPA), write to sales@infomatics.ai. If your data is in a customer's account, please contact that customer first, as explained in section 13.
Related documents: Terms of Service, Security, and the Data Processing Addendum (DPA), which is available on request from sales@infomatics.ai.
Write to contact@infomatics.ai and we will route your question to the right team.