Privacy Policy
Astragal S.A.S.
1. Who we are and what this policy covers
Astragal S.A.S. (“Astragal”, “we”, “us”) is a versioned REST API that decides, number by number, whether an outbound call placed by an artificial voice may be made today, and records why. You post a dial list and load or reference your consent evidence; we resolve each number to a jurisdiction, run a published rule ladder over it, and return a verdict of clear, hold or refuse carrying the rule pack version, the consent record, the scrub reference and an expiry. We place no calls. We carry no audio, run no dialer, hold no telephone numbering allocations, operate no part of a voice agent and are not a communications provider. We cannot start a call and we cannot stop one. We can clear a number, refuse to clear it, and record that a call went out uncleared.
Registered at Carrera 43A # 7-50, Oficina 1104, 050021 Medellín, Colombia.
We handle personal data in two different situations, and different rules apply to each:
| Whose data | Our role | What applies | |
|---|---|---|---|
| Part A | People who visit this website, ask about the service or write to us | Controller: we decide why and how the data is used | This policy |
| Part B | The telephone numbers on the dial lists you post, the consent records and disclosure text you load, the preference-list scrub references you supply, the call attestations you post back, and the operator accounts you authorize | Set out in B.1, because it depends on the data | This policy and the data processing agreement we sign with each customer |
If the data processing agreement (“DPA”) and this policy ever disagree about Part B, the DPA wins.
2. Part A: this website and our contact with you
This part covers the personal data we collect for our own purposes: running this website, answering requests, and staying in touch with people who are or might become customers.
A.1 What we collect
What you give us. When you send the form on this site, we collect what you type into it, such as your name, email address, phone number or company, and the fact that you agreed to be contacted. If you email or talk to us, we keep that correspondence and any contact details in it.
What is collected automatically. Our web server records the IP address a request came from, the browser used, the pages requested, the page you came from and the time. These logs exist to keep the site running and secure.
We don’t ask for sensitive data (the “special categories” in Article 9 GDPR) through this website, so please don’t send any through the form.
A.2 Why we use it, and what allows us to
| Why | What | Legal basis (GDPR Art. 6) |
|---|---|---|
| Answering your request and working out whether the service fits | What you sent in the form, our correspondence | Art. 6(1)(b): steps you asked for before a contract |
| Looking after customers, billing and support | Contact details, correspondence | Art. 6(1)(b): carrying out a contract |
| Keeping the site running, secure and free of abuse | Server logs | Art. 6(1)(f): our legitimate interest in running a secure service |
| Contacting you about the service | Email address, company | Art. 6(1)(f): our legitimate interest in business-to-business marketing. You can object at any time |
| Meeting tax, accounting and legal duties | Billing and contract records | Art. 6(1)(c): a legal obligation |
Where we rely on legitimate interest, we have weighed that interest against your rights, and you can ask to see the assessment.
A.3 How long we keep it
- Requests from people who don’t become customers: 12 months from our last contact, then deleted.
- Customer contact and contract records: for the length of the agreement plus ten years, the period Colombia’s Commercial Code sets for a company’s books.
- Server logs: 30 days.
- A record that you objected or opted out: kept indefinitely, so we can keep respecting it.
A.4 Your rights
If you are in the EEA or the UK, you can ask to see your data, correct it, have it deleted, limit or object to how we use it, get a copy you can take elsewhere, and withdraw consent where we rely on it. Write to [email protected] and we will answer within one month.
You can also complain to a data protection authority. If you are in the EEA, that can be the authority where you live or work.
3. Part B: data inside the service
Almost everything here is personal data and it belongs to your customers, not to you and not to us. A telephone number identifies a person. A consent record says what that person was told and what they agreed to, on what date, through which channel. An attestation says that person was called at a particular time and for how long. You are the controller of all of it; we hold it as your processor on your written instruction, and we use it for one purpose, which is to produce and evidence a per-number verdict. The one addition is confirmed disclosure wording, with its channel and field label and without numbers or identifiers: it also enters the shared coverage corpus described under training. What we do not want is the rest of the file. We do not need the account number, the balance, the arrears bucket, the customer's name, address or email, the call recording, the transcript, the agent identity or the disposition code, and none of those has a field in our schema. If they arrive inside a payload anyway they are dropped at ingest and are not stored.
B.1 What we handle, and in what role
Account data, meaning your work email, your company, your billing contact, your keys and the operators you authorize, we hold as a controller. The dial lists, the consent records and their disclosure text, the scrub references, the suppression list, the decisions, the attestations and the review queue history we process as your processor, on your instruction, for as long as your keys are live.
- The dial list. One row per number, in E.164, with your campaign id, a purpose from the fixed set, and an optional client reference of your own. We keep the submitted batch exactly as received alongside the verdicts we derived from it, because a decision has to be traceable back to the row that asked for it. Nothing else in the row is read: any additional field is stored unparsed against the row and is never an input to the ladder.
- Consent records and their disclosure text. For each consent event: the number it covers, the capture channel, the capture timestamp, the reference where a structured one exists such as a Digital Consent Acquisition reference, the purposes claimed, and the disclosure text the person was actually shown or read, stored word for word. The disclosure text is the evidence and it is kept verbatim, because a verdict that rested on paraphrased consent is worth nothing to your auditor. Where the record was captured by an IVR flow we keep the script identifier and the keypress, not the audio.
- Scrub references, suppression entries and revocations. The registered-preference scrub reference you supply with its date and the registry it came from, every entry on your own suppression list, and every revocation you post. A revocation is timestamped on receipt and invalidates every unexpired clearance on that number immediately, which is why we hold it rather than checking it once.
- Attestations, operator accounts and the decision log. The decision id, the time a call was placed against it and its duration, posted back by you. Who you authorize as a compliance reviewer, which proposals each of them confirmed or rejected in the review queue, and when. The log is written on every action, is append-only, and cannot be edited by anyone, ourselves included, because it is the record a regulator would ask to see.
Do not send us call recordings, transcripts, customer names, addresses, account numbers or balances. There is no lawful basis for them in this service and nowhere in the schema to put them. Unrecognized fields are dropped at ingest.
We hold no consent database, no preference registry and no scrub list of our own, and we do not acquire, buy, enrich or resell any. Every consent record and every scrub reference in your account came from you or from a registry you hold your own access to.
We never contact any person on a dial list, for any reason, including to verify a consent record. Your customers will not hear of us, and there is nothing in this product that could reach them.
B.2 What we do with it
Everything runs in one place. Ingestion, jurisdiction resolution, the rule ladder, both models, the review queue, the decision log, the attestation store and every export run on cloud infrastructure in Columbus, Ohio. We operate no second location and no processing of any kind happens outside it.
No third-party inference, at any point. Both models run on cloud GPU capacity we control in Columbus, Ohio. No telephone number, no disclosure text, no consent record, no scrub reference and no attestation is sent to a hosted model API. There is no model vendor on our subprocessor register, because there is no model vendor in the path.
The two corpora are governed differently. The coverage corpus holds a disclosure wording, its capture channel and its field label mapped to the coverage verdict a human reviewer confirmed. It carries no telephone numbers, no consent record identifiers and no customer identifiers, and it is shared across the service. The matching corpus holds pairs of identifiers from two of your own systems with a human decision about whether they refer to the same person; that is specific to your books, so it is partitioned to your account, never pooled, and never used to train anything that touches another customer's decisions.
A decision is never edited. Once issued, a decision object is immutable: its verdict, its rule identifier, its rule pack version, the consent record and scrub reference it rested on, and its expiry do not change. A clearance can expire and it can be revoked, and both of those are new records that reference the original. Nothing overwrites a decision, because a call may already have been placed against it.
Your rates are never compared with anyone else's. We publish no clearance rate, no refusal rate, no benchmark and no aggregate drawn from any customer's dial lists or consent books, and we would have to build something we have deliberately not built in order to do so. The one number we publish about ourselves is our price.
B.3 AI models: where they run and what they learn from
Where models run. All inference runs on cloud GPU capacity we control in Columbus, Ohio: the fine-tuned classifier that reads a free-text consent disclosure together with its capture channel and field metadata and proposes a coverage verdict, and the embedding model that proposes whether a consent record in one of your systems refers to the same person as a record in another. No third-party inference endpoint is used at any point. No telephone number, no disclosure text, no consent record, no scrub reference and no attestation is sent to a hosted model API, and there is no model vendor on our subprocessor register because there is no model vendor in the path. We operate no second location, and every stage of the service, ingestion through export, runs on cloud infrastructure in Columbus, Ohio.
Training. We do not train on your data, and the exception is narrow enough to state exactly. Two corpora accumulate from reviewer decisions and they are governed differently. The coverage corpus holds a consent disclosure wording, the channel it was captured through and the source field label it arrived in, mapped to the coverage verdict a human confirmed, being which purposes it covers and whether an artificial or prerecorded voice was disclosed. It holds no telephone numbers, no consent record identifiers, no campaign identifiers and no customer identifiers, and it is shared across the service. The matching corpus holds pairs of identifiers from two of your own systems with a human decision about whether they refer to the same person; that is specific to your books, so it is partitioned to your account, never pooled across customers, and never used to train, tune or evaluate anything that touches another customer's decisions. Your dial lists, your scrub references, your attestations and your decision log are used to train nothing at all.
Where a person decides. The model proposes and a person decides, in both places a model runs, and the model's authority is bounded on one side only: it can produce a hold and it can produce nothing else. A proposed coverage verdict is applied to a consent record only when its score clears a fixed threshold and one of your named compliance reviewers confirms it in the review queue, against the stored disclosure text, one wording at a time. Below the threshold nothing is guessed at: the record stays unreviewed, every number resting on it returns hold with the missing artifact named, and a dial list cannot be fully cleared while proposals sit unreviewed, with no override for you or for us. A verdict of clear or refuse is issued only by a rule with its identifier printed on the decision, never by a model output. No automated decision producing legal effects for any individual is made anywhere in this service: Astragal does not place a call, does not choose who is dialed, does not build a dial list, does not score a person and does not decide anything about the customer behind a number beyond whether the evidence you hold supports calling them under a published rule.
B.4 Where the data is kept
All storage and all processing sit on cloud infrastructure in Columbus, Ohio. Dial lists, consent records, disclosure text, scrub references, suppression entries, decisions, attestations, both model corpora and the review queue history are held there and nowhere else.
No inference runs on a third-party endpoint. The coverage classifier and the consent-matching embedding model run on cloud GPU capacity we control in Columbus, Ohio.
Webhook deliveries leave our infrastructure, because a webhook goes to the endpoint you registered, wherever you run it. The payload carries the decision id, the number, the verdict and the reason code, and nothing else; you choose the destination and you can require mutual TLS on it.
Support access to a customer account is granted case by case, is recorded in the same append-only log as everything else, and is performed only by named members of our staff.
The suppliers that handle data in the service are named on our subprocessor list, which comes with the data processing agreement and which we send to anyone who asks: write to [email protected].
B.5 How long we keep it, and what deleting can’t remove
Dial lists as submitted, decisions, the rule pack version behind each one, and the attestations posted against them: for the life of the account and 24 months after the last key is revoked, because a call placed in March is argued about long after March. Earlier deletion on written instruction.
Consent records and their verbatim disclosure text: for the life of the account and 24 months after, matching the decisions that rest on them. A consent record deleted on your instruction invalidates every unexpired clearance that rested on it, immediately and automatically.
Revocations: retained for the life of the account plus 24 months even where the underlying consent record is deleted, because the evidence that someone withdrew consent outlives the evidence that they gave it.
Scrub references and suppression entries: for the life of the account plus 24 months.
Review queue history, including who confirmed or rejected each proposal and when: for the life of the account plus 24 months, unedited.
Matching decisions in the corpus partitioned to your account: deleted with the account, within 30 days of the last key being revoked.
The shared coverage corpus: retained indefinitely. It holds disclosure wordings, capture channels and field labels mapped to a verdict, and carries no telephone numbers and no customer identifiers.
Account and billing records: ten years after the account closes, as Colombia's Commercial Code provides. Request and delivery logs without payloads: 90 days.
B.6 Requests from people whose data is in the service
The people behind the numbers on your dial lists are your customers, not our data subjects, and we hold no way to reach them and no intention of acquiring one. If someone writes to us directly about a number we will not answer on the substance; we will tell them plainly that the lender or insurer who holds their account is the controller, name you, and forward the request to your nominated contact within five working days. On your written instruction we will locate, export or delete every record relating to a named number, including its consent records, its decisions and its attestations, and where deleting a consent record invalidates an unexpired clearance that happens immediately and is written to the log rather than done silently. A revocation posted through the API takes effect on receipt and needs no instruction from us. About your own operators we hold work email, name and the review queue entries attributable to them; write to [email protected] and we will answer within 30 days.
For everyone
4. Moving data between countries
Astragal S.A.S. is a company in Colombia, outside the EEA, and handles personal data under Colombia’s Law 1581 of 2012 and, where it applies, the GDPR. Section B.4 says where the data in the service is kept. When personal data from the EEA or the UK reaches us, for example because someone there writes to us or a customer there uses the service, it is protected by the European Commission’s Standard Contractual Clauses and the technical measures described in our security documentation. You can ask us for a copy. In Colombia you can complain to the Superintendencia de Industria y Comercio.
EU representative (Article 27 GDPR). Write to [email protected] with “EU representative” in the subject line and we will send you our representative’s details.
5. Security
We protect data in line with the risk. That includes encryption in transit and at rest, access limited to the people and systems that need it, each customer’s data kept separate from every other’s, and a log of every access to production systems.
If a personal data breach affects you, we tell you without undue delay, and at the latest within 36 hours of finding out, with the information you need to meet your own reporting duties.
6. Children
The service is sold to businesses and is not meant for children. We don’t knowingly collect personal data from anyone under 16.
7. Changes to this policy
We may update this policy. If a change matters, we email customers at least 30 days before it takes effect. The version number and date at the top of this page change every time.
8. Contact
Privacy questions and anything else: [email protected]
By post: Astragal S.A.S., Carrera 43A # 7-50, Oficina 1104, 050021 Medellín, Colombia