Privacy Policy

1. Who we are

Amy is operated by [To be supplied: the registered name of the company that operates Amy], registration number [To be supplied: the company's registration number], of [To be supplied: the company's physical address]. In this policy "we", "us" and "our" mean that company.

• Our Information Officer is [To be supplied: the name of our Information Officer].
• General questions: [To be supplied: our general contact email address].
• Requests about your personal information: [To be supplied: the email address for data requests] (see section 10).

2. Our two roles

POPIA gives us a different role for each of two kinds of information.

• Account information: we are the responsible party. This is the information about the people who sign up for Amy and use it. We decide why and how it is processed, and this policy is our notice to you about it.
• Customer content: we are an operator. This is what a customer puts through Amy: instructions, messages, files and the results Amy produces. The customer is the organisation the account belongs to. That can be an outside organisation, or the company that runs one of our own products. The customer is the responsible party for any personal information in that content. We process it only on the customer's behalf and on its instructions, as our Terms of Service set out.
• Our own products. Where we ourselves run a product that is built on Amy, there is no separate customer. We are the responsible party for that product's information, and that product's privacy policy is our notice to you about it.

If you use a product that is built on Amy, the organisation that runs that product is the responsible party for your information, and its privacy policy applies. Send your request to that organisation. Amy has no account for an end user, and the API that starts work has no field for an end user's name or contact details. Where the organisation gives Amy a reference for you, Amy stores your information under it. Amy does not ask who the reference stands for, and our Terms require that it does not identify you. The content the organisation puts through Amy can still name you. If you write to us, we will tell you to contact that organisation. This is about a product run by another organisation. Where we run the product ourselves, write to the address in that product's privacy policy.

3. What we collect, why, and on what basis

This table covers account information, for which we are the responsible party. Each row names a kind of information and what it includes. A row is not a list of every field Amy stores.

• Where it comes from. Mostly from you. Other sources include these. If you sign in with Google or GitHub, that provider gives us information that includes your name, your email address, your profile picture, its identifier for your account and the tokens for that sign-in. If someone invites you to an organisation, that person gives us your email address. Someone else can also type your email address into Amy. On the sign-in page, Amy then emails a sign-in link to it, or counts a failed sign-in against it. On the sign-up page, if the address has no account yet, Amy creates an account under it with the name and password that person chose, and emails the address to verify it. Amy refuses a sign-in with that password until the address has been verified from an email sent to it. On the account page, a person can ask to change their own address to yours, and Amy can then email yours to verify it.
• What is required. An email address and a way to sign in are required to create an account, and the sign-up form requires a name. Without them we cannot give you one. An account that is first created by an emailed sign-in link starts with no name, and Amy shows the part of the email address before the @ in its place. A profile picture and a time zone setting are optional. Most of the rest of what the table lists is recorded automatically as you use Amy.
• Why we collect it. We collect it to provide Amy to you. We do not collect it because a particular law requires us to.
• Consent. We do not rely on your consent for anything described in this policy. If we ever ask for your consent, you can withdraw it at any time.
• Email. The emails Amy sends are account emails, including emails to verify your address, to sign you in, to reset your password, to confirm a change of email address, and to deliver an invitation. We send no marketing email.
• Automated decisions. We make no decision about you that has a legal or similarly serious effect on you and is based only on the automated processing of your personal information. An automatic step that does act on your account: after repeated failed sign-ins with a password for an email address, Amy first delays and then locks sign-in with a password for that address. A delay ends by itself. A lock is lifted when you sign in another way, such as with an emailed link, or reset your password.
• Selling and advertising. We do not sell personal information, and we do not share it for advertising. Amy carries no advertising and no analytics trackers.

4. Customer content

When Amy does work for a customer, it stores what the customer puts in, what the customer sets up and what the work produces. That includes:

• the instructions and the messages of conversations;
• tool calls, with what was sent to the tool and what came back;
• the questions Amy asks during the work, and the answers given;
• files that are uploaded, and files that Amy produces;
• the memories an agent keeps;
• for a team of agents: the goal it was given, its plan, the results of its steps and its summary;
• the agents, teams, schedules, tests and connections to tools and providers that the customer sets up, and records a member creates in the app, such as an invoice;
• records of runs and what they cost.

Content is stored under an end-user reference where the work carries one. A customer that starts work through the API chooses the reference, and our Terms require that it does not name or directly identify a person. Work started inside the Amy app, on a schedule or in a test can carry the user identifier of the member who started it, a reference that Amy makes from the schedule or the test, or no reference.

Work that carries no reference cannot be erased for one end user (see section 8). That includes a run started through the API with no reference, and a team's work that a member starts from the team's Runs page, or that a schedule or a test starts.

We process customer content only to provide Amy to that customer. The customer decides what goes in, and must have a lawful ground for any personal information it contains.

5. Special personal information and children

• We do not ask for special personal information in your account. Under POPIA that is information about your religious or philosophical beliefs, race or ethnic origin, trade-union membership, political persuasion, health or sex life, or biometric information, and information about criminal behaviour: an alleged offence, or the proceedings about one. Please do not put any in your profile.
• Customer content may contain special personal information, for example health information. The customer is the responsible party for it and must have the legal ground POPIA requires. We process it only on the customer's instruction. Our Terms of Service say more.
• Amy accounts are for adults. You must be 18 or older to create one. We do not knowingly collect account information from a child. A customer that puts a child's personal information through Amy must have the prior consent of a competent person, or another ground POPIA allows.

6. Who receives it

We use the companies below to run Amy.

• Railway, Cloudflare, Resend, Sentry and Anthropic are our operators. They process information for us, to provide their service to us.
• Google, GitHub and PayFast are not our operators. You deal with each of them directly, and each handles your information under its own privacy policy.

• Your organisation. The other members of an organisation you belong to can see your name, your email address, your role and the date you joined. They can also see what is set up and shared in the organisation: its agents, teams and invoices, the name and size of a file attached to an invoice, its projects and the files kept in a project where there are any, and the organisation's usage figures and statistics; that includes members with a read-only role. Your runs with their messages, your chats and your own files (those you uploaded and those your runs made) can be read only by you and by the organisation's admins. Its admins can also see the audit log of what was done in the organisation, and the invitations that are still open.
• AI and other providers. The AI, speech, search and other providers that are connected for an organisation receive what the work sends them. A run sends its content to the provider of the model it runs on. A step that reads an image or a document, handles speech, makes or edits an image, searches the web, or saves or searches memories sends what that step needs to the provider set up for that step, which can be a different company. That includes images, documents and sound, the text, question or instruction sent with them, search words, and the text of memories and of run summaries. The microphone in the Amy app sends your recording to the speech provider, also when no run is under way.
• The key we supply. Where we have agreed to supply the provider key for an organisation, the provider is Anthropic, our operator, and its terms say this: Anthropic may not train its models on our content sent through the API, and it deletes inputs and outputs from its backend within 30 days of receipt or generation, except where it must keep them to enforce its usage policy or to comply with the law, or has agreed a different period with us.
• A customer's own provider key. A customer, or one of its members for their own work, can connect its own key for a provider Amy supports. Which key a run uses depends on how it was started: a member's, the organisation's, or ours where we have agreed to supply one. A provider reached with a customer's or a member's key is their choice, and it receives the content under their own agreement with it. It is not one of our operators. It handles the content under its own terms, and we make no promise on its behalf about how long it keeps content or whether it uses content to improve its models.
• Tools and addresses a customer connects. A customer can connect its own tool servers, and can register a web address to be told about events such as a run finishing. A tool server receives what a run sends to that tool, which can include the end-user reference and the identifiers of the run, the conversation and the agent. The registered address receives a notice of an event, including identifiers, the names of an agent and a tool, times, the state and result codes of the work, how much it used, the end-user reference and, for an invoice, its number. Both are the customer's choice, and neither is one of our operators.
• Images from the web. A run can fetch an image from a public web address that a person gave it or that a web search returned. That site receives a request for the image from Amy's server.
• What Sentry receives. Sentry receives error reports, log lines, traces and, when your browser has an error, a recording of the page. Each can hold personal information. What it holds depends on where it comes from, and includes:
  • From your browser. The route of the page, the kind of error and where in Amy's code it happened, the routes of the pages you opened and of the requests your browser made shortly before, and what you clicked or typed into shortly before, described by the kinds of the elements and the identifier and style names they have in the page. A route is the pattern of an address, with a name in the place of each value, such as an identifier. For a request to another site, the report holds the name of that site and not the path, unless the path is spelled like a route of Amy's own. Amy leaves out the labels of what you clicked or typed into, which can hold a name, a file name, the goal of a run or a web address. Your browser sends the report to the Amy web app, which passes it on to Sentry. The Amy web app passes on the report and nothing of your request, so Sentry does not see your IP address, and the report does not hold the kind of browser you use. The Amy web app sees your IP address and the kind of browser, as it does for every request. A browser sends no log line and no trace.
  • A recording of the page, when your browser has an error. Amy records the page in your browser and keeps the last minute of it in the browser. When an error happens, Amy sends that minute to Sentry, with the error, and then stops recording, so what you do after the error is not sent. Without an error, nothing of the recording leaves your browser. All text on the page, everything you type into a field and the value of every field and button, also one that the page fills in itself, is hidden in the recording, and images, video and other media are left out. A hidden text still shows how many characters other than spaces it had. The recording shows the layout of the page, the kind of each element and a short fixed list of its details, such as the kind of a field and whether it is checked, and your clicks, scrolling and pointer movements. A click is described only by kinds of element, taken from a fixed list of names, such as a button inside a form. The identifier and style names of the elements, and the text of the page's own style rules, are left out. It also holds the pages you opened, the requests your browser made, with the result code, and where a link points. Each is shown as a route, with a name in the place of each value and nothing after a "?" or a "#". For another site it holds the name of that site and not the path, unless the path is spelled like a route of Amy's own. The recording is not sent with the kind of browser you use, and the page you came from is sent as a route. It passes checks of its own: Amy sends only what is on a list of what may leave, and a recording that cannot be checked is not sent.
  • From the Amy web app. The method and the route of the page, the kind of error and where it happened, the requests the web app made shortly before, and details of the server. Also its log lines, and a trace for some of the requests it serves, as described below.
  • From the Amy API. The method and the route of the request, and not the address itself or anything after a "?". Three headers of the request: the kinds of content it accepts, the kind of content it sent and the length of that content. No other header, so not an Amy API key and not a forwarded IP address. The identifiers of the user and the organisation, where a log line of Amy's own holds them. The kind of error, where it happened and, for an error of Amy's own, its text. Recent log lines that Amy's own code wrote. For recent calls the API made to providers, to a customer's tool servers and to a customer's registered web address: the site that was called, the method and the result code, and not the path or anything after a "?". Also its log lines, and a trace for some of the requests it serves, as described below.
  • Log lines. The Amy web app and the Amy API send Sentry log lines. In the service you use, these are the lines they write at warning level and above, and not the lines that only record that something happened. The test copy of Amy that we run to check a release before it goes live also sends the lines that record that something happened, such as each request it served. A log line goes with its fixed text, and not the values filled into it, and with a few named fields. From the Amy API these include the method, the result code, the time taken and the name of the code that wrote the line. From the Amy web app they include the method, the route, the result code, the time taken, other numbers, and any field whose name ends in "Id" and that holds an identifier Amy made or a number, such as the identifier of a user or of an organisation. Any other field is left out, and so is a value that does not fit its field. A line that software Amy uses wrote, and not Amy's own code, goes the same way: with its fixed text and without its values.
  • Traces. For about one request in ten, the Amy web app and the Amy API send Sentry a trace of it: the route of the request, the method, the result code, how long each step took, the identifiers that tie the web app's part of the request to the API's, the version of Amy and details of the server. For a call Amy made to a provider or another site while serving the request, a trace from the Amy web app holds the name of that site. One from the Amy API holds the name of that site and no part of the path. The name of the site can be one that a customer or a run chose, as in a customer's tool server or the address of an image a run fetched. A trace from the Amy API also holds the three headers of the request named above. It holds none of the recent log lines that a report holds. A trace holds no cookie, no body and no database query, apart from a single word such as "BEGIN".
  Before an error report leaves your browser or the web app, Amy removes the fields that hold your user identifier, name and email address, the cookies and the request headers. It also removes what follows a "?" or a "#" in the field that holds the page's address, and in the addresses it recognises among the pages and requests recorded before the fault. That is the least Amy removes, and not a description of the whole report: the text of an error of Amy's own, or the identifier or style name of an element, can still hold a value from the page or the request, or from the work Amy was doing, and we have not confirmed otherwise. An error report from your browser or the Amy web app can also hold the wording that the browser or the web app's software gives a common kind of error, such as "Cannot read properties of undefined (reading 'plan')": it keeps the short words that the wording names, such as plan, and puts a placeholder in the place of any other value, such as other quoted text, a number, a long text or one that starts like some providers' keys, or an address. A word that it keeps is usually a name in Amy's code, but it can be text of up to 32 characters taken from the data Amy was working on, such as a surname or a key the rules do not recognise, and we have not confirmed otherwise. Before an error report leaves the Amy API, Amy puts the route in the place of the address that was requested, and removes what follows a "?", the user fields and every request header except the three named above. A report from the API leaves out cookies and the value of the sign-in token. Log lines and traces pass checks of their own: each is rebuilt from a list of what may leave, and a field that is not on the list is left out. The text of an error or of a log line of Amy's own can still hold a value from the request, or from the work Amy was doing, and we have not confirmed otherwise. Every call the Amy web app makes to the Amy API carries Sentry's trace headers. A call by the Amy web app or the Amy API to any other party carries no Sentry header, and no text your request sent in a baggage or tracestate header. A trace id that a request sent to the Amy API in a traceparent header is passed on to the calls the API makes. The Amy web app does not pass on one that a request sent to it. One exception to what is said above about request headers: Sentry is not such a party, and an error report can carry text that your request sent in a baggage header under a name that starts with sentry-, and then only as an identifier, a number or a short label.
• The law. We disclose personal information to an authority when the law requires us to.
• Changes to this list. Before we add a company or a country to this list, we will update this policy and tell account holders by email or inside Amy.

7. Transfers outside South Africa

Some of the companies in section 6 store or process information outside South Africa. For each one, the table there names the country or countries and says what protects the information there.

• For account information, the transfer is necessary to perform our contract with you: Amy runs on these services and cannot be provided without them. Where the table says a written agreement protects the information, we rely on that agreement as well.
• For an invitation sent to a person who has no account yet, the transfer is necessary to perform a contract, made in that person's interest, between us and the organisation that invited them.
• For customer content, we transfer it as the customer's operator, on the customer's instruction. The customer agrees to our operators and their countries in our Terms of Service. The customer is responsible for having a ground under POPIA for that transfer, and for any authorisation the Information Regulator must give before special personal information or a child's personal information is transferred.

8. How long we keep it

What stays behind after a deletion:

• When you delete your account, your account record, your sessions, your password hash and your sign-in details with Google or GitHub are deleted at once. The account record holds your name, email address, profile picture and time zone. An organisation of which you are the only member is deleted with it. There is no waiting period and no way to undo it. A deletion that fails partway can leave the account or the organisation in place: if that happens, write to us. Amy also deletes the file of your profile picture where it finds it in the organisation you are working in at that moment. The file can stay behind, for example where you uploaded the picture while working in another organisation: it then stays in that organisation as a file.
• Records that hold your email address can stay after your account is deleted. They include the record of failed sign-ins for that address, if there is one; an invitation that another organisation sent to that address, which stays with that organisation; and the record behind an emailed sign-in link that has not yet been cleared. The table above says how long each is kept.
• In an organisation that you shared with other people, you are removed as a member. What you did there stays with the organisation. That includes your work, the files you uploaded, the API keys you created, which keep working, and a provider key you connected for your own use. It stays marked with your user identifier. Amy removes your name from the organisation's list of members in one step that can fail: if that step fails, your name can stay there. Content that mentions your name, such as a message or a memory, is not changed, and an organisation that was named after you keeps its name. An export of the organisation's information that an admin made earlier still holds your name until it is deleted, which is within 31 days of its being made (longer only if the file store cannot be reached), or sooner if an admin deletes it. The audit log keeps the user identifier, and for a sign-in the IP address, until the entry is 12 months old.
• You cannot delete your account while you are the only admin of an organisation that has other members. Make another member an admin, or remove the other members, first.
• When a customer erases an end user, Amy deletes what it finds stored under that end user's reference at that moment. That includes the memories, and the runs with their messages, tool calls and results, and the questions and answers that belong to them. It also deletes an output file that one of those runs produced, or a file that was uploaded through the API for one of them, unless a run that is not being erased also uses the file.
• An erasure has limits. What it does not delete can stay until the organisation is deleted, and some records for longer, as the table above says. The limits include these.
  • Work with no reference. An erasure does not reach work stored without that reference. That includes a run that was started with no end-user reference and the memories from it, and a team's work that a member started from the team's Runs page, or that a schedule or a test started.
  • References an erasure does not work for. An erasure made in the Amy console, or through the API with the reference in the body of the request, looks for the reference exactly as it was stored. An erasure through the older API route, which takes the reference in the web address, does not work for a reference that holds a "/", a "%", a space or a character other than plain letters, digits and punctuation, or that is "." or "..". For a reference that holds a "?" or a "#", that route works only if the client encodes the character in the web address. A client can cut off a "#" and what follows it, and a "?" at the end, before it sends the request, and that route can then erase what is stored under the part of the reference before that character. We have not confirmed that an erasure works for each other reference. If an erasure does not work, write to us.
  • A run that is still executing. If one of that end user's runs is executing when the erasure is made, Amy does not stop it, and what that run stores afterwards is not covered by that erasure. An erasure made at that moment can also fail, and then erases nothing. Erase when the end user has no run executing, or repeat the erasure once the run, and any background task it started, has finished. A repeat does not remove a file that the run produced after the first erasure.
  • A team's record. An erasure does not delete the record of a team of agents working for that end user: the goal it was given, its plan, the result of each step or the reason it was turned down, its summary, and the questions it asked with their answers. Where the team's work carries the reference, the runs and messages inside it are deleted.
  • Some files. An erasure does not delete a file that a team saved to its shared files, a file that a member uploaded, or an export of the organisation's information that an admin made earlier. An export is deleted within 31 days of being made.
  • Records of what happened. An erasure does not delete the audit log, the usage records or the records of what was sent to a registered web address. These hold identifiers, which can include the end-user reference. An audit entry can also hold a short label from the work, such as the name an agent gave a memory.
  • A model chosen for a conversation. Where a member chose a model for a conversation in the Amy app, an erasure does not delete the record of that choice. It holds the member's user identifier, the conversation's identifier, and the name of the model and of its provider, and no messages.
  The customer can still link the reference to a person.
• Backups. Deleting or erasing information does not remove it from a database backup that was made earlier: it stays there until that backup expires. The file store keeps no earlier version of a deleted file.
• What has already been sent out is not recalled. A deletion or an erasure does not reach content that an AI provider, a customer's tool server or a registered web address has already received.

9. How we protect it

• Connections between your browser and Amy are encrypted.
• Amy stores a one-way hash of a password, not the password itself.
• The keys a customer connects for AI and other providers are encrypted before they are stored. Amy keeps the last four characters of a key unencrypted, to show which key it is.
• Amy keeps each organisation's information apart from other organisations'. Where the database enforces that separation itself, it covers records that include the audit log and the runs. Elsewhere Amy's own code enforces it. That includes the contents of stored files, API keys, queued background work, stored answers to repeated requests, and the records of accounts, memberships and invitations.
• The web app and the API run under separate database accounts, each with rights to its own part of the database. A separate account with wider rights changes the structure of the API's part of the database when a release is installed. The web app's account changes the structure of its own part.
• Sign-in with a password is locked after repeated failed attempts.
• The database accounts the API runs under can add an entry to the audit log and have no right to change or delete one. Entries are removed when they are 12 months old.

No system is perfectly secure, and we cannot promise that a breach will never happen.

If there is a breach. If we have reasonable grounds to believe that personal information was accessed or acquired by someone not authorised to, we will notify the Information Regulator and the people affected as soon as reasonably possible, in writing. The notice will set out the possible consequences, what we are doing about it, what you can do to protect yourself and, if we know it, who got access. Where the information is customer content, we will notify the customer immediately. The customer is the responsible party for it, and notifies the Information Regulator and the people affected.

10. Your rights and how to use them

Under POPIA you have the right to:

• be told that we collect personal information about you, which is what this policy does;
• be told if your personal information was accessed or acquired by someone not authorised to;
• ask whether we hold personal information about you, ask for a record of it, and ask who has had access to it;
• ask us to correct or delete personal information that is inaccurate, irrelevant, excessive, out of date, incomplete, misleading or obtained unlawfully;
• ask us to destroy or delete a record that we are no longer allowed to keep;
• object, on reasonable grounds, to processing that we do on the basis of a legitimate interest;
• object at any time to processing for direct marketing, which we do not do;
• not be subject to a decision that has a legal or similarly serious effect on you and is based only on the automated processing of your personal information;
• complain to the Information Regulator;
• go to court over an interference with the protection of your personal information.

What you can do yourself in Amy

• Correct your name, email address, profile picture and time zone on your account page. A member with a read-only role cannot upload a new picture while working in that organisation.
• Delete your account on your account page. It asks for your password. If you have none, because you sign in only with Google, GitHub or an emailed link, set one first with the password reset on the sign-in page, or write to us.
• An organisation admin can export the organisation's information, erase one end user's content, and delete the organisation. Section 8 says what an erasure removes and where it stops. An export includes the organisation's set-up, its members by display name and role, its team records, its usage records, its invoices and subscription, its notifications, its audit log and a list of its files. It does not hold everything. Among what it leaves out: runs and the conversations in them, the content of memories, the contents of files, members' full email addresses, invitations, and the IP addresses in the audit log. It does hold each schedule's message and the first part of a background task's final answer. A member with no name is listed by the part of the email address before the @. Write to us if you need any of these.

How to make a request

• Write to [To be supplied: the email address for data requests]. A plain email is enough. The POPIA Regulations provide Form 1 for an objection and Form 2 for a correction or deletion. You may use them; we do not require them. Asking whether we hold personal information about you, objecting, and asking for a correction or a deletion are free.
• We check that you are who you say you are before we act. We do it by asking you to show that you control the email address the account is under.
• We answer as soon as we reasonably can, and at the latest within 30 days of the day we receive your request. Checking your identity does not stop that clock.
• If you object to processing on reasonable grounds, we stop that processing, unless a law requires it.
• If you are an end user of a product that another organisation built on Amy, we will send you to that organisation (see section 2).

11. Complaints

Please tell us first, so that we can try to put it right. You can also complain to the Information Regulator (South Africa) at any time:

• Website: https://inforegulator.org.za
• Complaints: POPIAComplaints@inforegulator.org.za
• Address: Woodmead North Office Park, 54 Maxwell Drive, Woodmead, Johannesburg, 2191

12. Cookies and browser storage

Amy uses cookies and browser storage for purposes that include signing you in, remembering how you like the app to look, keeping your place on a page, and showing the result of a checkout once. One cookie in the list is written and not yet read. Amy itself sets no advertising or analytics cookies, so it shows no consent banner. This is the list of what Amy itself puts in your browser. When you sign out, Amy asks your browser to clear the cookies.

13. Changes to this policy

When we change this policy we publish the new version here and change the date at the top. If a change affects how we use information we already hold about you, we will tell account holders by email or inside Amy before it takes effect.