What Information May MYLO Send to an AI Provider?

MYLO can use a customer-selected AI provider to understand a question, interpret selected material and help prepare an explanation or proposal. That means some information may leave the appliance when an authorised user invokes an AI-assisted feature. The accurate privacy promise is not “nothing ever leaves.” It is that MYLO should send only the purpose-limited context needed for the selected task, keep protected credentials out of the model path, and make the boundary understandable to the customer.

The customer owns the provider relationship: account, key, model choice, billing, terms and provider-side retention settings. Before using the feature, the business should decide what kinds of information it permits staff to submit and confirm that the selected provider arrangement fits its obligations.

The user’s question is part of the request

When a person asks MYLO an AI-assisted question, the wording of that question may be sent to the configured provider. A request such as “Create a support IVR for sales, billing and emergencies” contains less sensitive detail than a message filled with customer names, private phone numbers or passwords. Users should write the minimum useful question and avoid adding data merely because a chat box accepts it.

The question can also reveal business context: department names, opening hours, vendor names, system symptoms or intended call volumes. That information is not necessarily a secret, but it is still data leaving the local appliance for the requested processing. Staff should know this before pasting internal incident narratives or customer complaints.

MYLO authentication and page access determine who may use the feature. They do not transform inappropriate input into safe input. Training should include a simple rule: ask for the business outcome, provide only relevant context, and never paste credentials.

Selected context can accompany the question

An answer is more useful when MYLO supplies relevant context, such as the supported product behaviour, a bounded observation or a selected document. Context should be chosen for the task rather than assembled as an unrestricted dump of the appliance.

For example, to explain why an endpoint is not registering, the useful context may include the endpoint’s non-secret identity, current Asterisk status, a bounded failure category and the user’s question. The AI provider does not need the entire user database, every call record, all system logs or the endpoint password to help describe the evidence.

Source-of-truth boundaries still apply. Asterisk remains authoritative for live telephony state and Linux for live network state. The AI receives a selected representation and can help interpret it; it does not become the authority or obtain permission to perform arbitrary actions.

Documents should be sanitized before processing

Telecom provider documents often mix useful meaning with sensitive values. A configuration sheet may describe registrar, transport, number format, authentication method and routing instructions alongside an actual username and secret. MYLO can preserve the structural meaning while replacing protected values with typed placeholders.

A sanitized representation might show that an authentication username exists, that a secret is required, or that a provider address belongs in a particular field without sending the real protected value. This allows the model to reason about the document’s structure and identify missing business decisions.

Sanitization is a control, not a guarantee of anonymity. Free text can contain people’s names, telephone numbers, account references or commercial detail that an automated detector cannot classify perfectly. The user should review documents, submit only what is necessary and follow the organisation’s retention and data-handling policy.

Credentials are excluded from ordinary model context

SIP authentication secrets, endpoint passwords, administrator passwords, AI-provider keys, private keys and similar protected values do not belong in chat or AI prompts. MYLO’s design keeps the values in protected local handling and uses deterministic code to resolve them only at the authorised execution boundary.

This separation is practical, not cosmetic. The language model usually needs to know that a trunk uses credentials, not the credentials themselves. If a proposal is approved, local services can populate the protected field, validate the configuration and apply it without exposing the value to the model.

Ordinary logs, run events and attachments should follow the same rule. A system that removes a password from the prompt but copies it into an error message has not protected it. Diagnostic output should report presence, failure type and correlation evidence without echoing the secret.

The customer-selected provider receives the request

MYLO uses the provider and credentials configured by the customer. The provider may process the prompt and selected context according to its service terms, location, security controls and retention choices. MYLO cannot make a universal promise about every provider or account plan.

The business should review the provider’s current contractual and technical details directly. Questions include whether prompts are retained, whether they are used for model improvement, where processing occurs, who may access the account, and how keys are rotated or revoked. These answers can change and should not be inferred from an old MYLO article.

Using a customer-controlled key makes billing and provider choice explicit. It does not remove the customer’s responsibility to select an appropriate provider or to control which staff can invoke AI-assisted processing.

What normally stays local

Local authoritative systems retain responsibility for execution. Asterisk configuration, Linux networking, protected credentials, role enforcement, approvals, snapshots and deterministic operations do not become model-controlled simply because AI assisted with the language.

MYLO can send a sanitized explanation of current state without sending an unrestricted raw system image. It can ask the model to draft a proposal while local code validates every structured value. It can request clarification while leaving the existing PBX running. A model response is advice or structured intent until the authorised MYLO workflow accepts it.

Campaign pacing, retry decisions, capacity, caller-ID rotation and state transitions are deterministic responsibilities. Active calls should not wait for an AI answer. This keeps the processing boundary proportionate to the semantic task.

A concrete example

An administrator uploads a provider document and asks MYLO to prepare a trunk proposal. Local processing identifies fields representing a username, password and provider address. Protected values are removed or represented by typed placeholders. MYLO selects the sanitized configuration meaning and the user’s requirement for the configured AI provider.

The model may explain the document, note that the business has not specified an outbound caller ID, and produce a structured proposal. It does not receive the SIP password and does not write the Asterisk file. The administrator reviews the proposed difference and approves only after the missing decision is resolved.

Deterministic local code retrieves the protected values through the correct boundary, takes a scoped pre-change snapshot, writes the approved configuration, validates it, reloads Asterisk and verifies a real call. The operation record shows the selected context classification and outcome without reproducing credentials.

Customer checklist before enabling AI assistance

• Identify the configured AI provider, account owner, billing owner and key custodian.
• Review the provider’s current terms, retention choices and geographic processing.
• Define which users may invoke AI-assisted features and what data they may submit.
• Keep SIP secrets, passwords, API keys and private keys out of questions and attachments.
• Use selected, bounded context rather than whole databases or unfiltered logs.
• Review sanitized documents for free-text personal or commercial information.
• Confirm that consequential changes still require local validation and approval.
• Reassess the arrangement when the provider, model, policy or business use changes.

The useful privacy statement is therefore specific: MYLO may send the user’s question and selected, purpose-limited, sanitized context to the customer’s configured AI provider. Protected credentials stay outside ordinary model context, and deterministic local systems remain responsible for authorisation and execution.

Classify requests before sending them

A simple classification helps users make consistent decisions. A low-sensitivity request may ask for an explanation of a generic telecom concept. A business-context request may include department names, operating hours and a sanitized design. A restricted request contains credentials, private keys or other material that must not enter ordinary AI context. Personal customer data needs a specific permitted purpose and the minimum necessary scope.

The interface and operating procedure should encourage the user to recognise the category before submission. Where MYLO supplies context automatically, the product should select bounded evidence relevant to the question and avoid broad history by default. An administrator should be able to explain the rule to staff without relying on a vague claim that “the AI is secure.”

Audit records should capture useful metadata—requesting user, feature, provider, context category and outcome—without becoming a second copy of the entire prompt or protected document. Retention for conversational history, uploaded originals and sanitized derivatives should be defined separately where their risks differ.

If the business cannot determine whether a document may be sent, stop and obtain the appropriate privacy, contractual or legal review. MYLO’s sanitization and access controls support that decision; they do not replace the organisation’s accountability.

Context Is Not the Same as Credentials

Approved model context may include a business description, relevant conversation context, selected reference knowledge and sanitized technical information needed to understand the task. Protected credentials, real passwords and unnecessary private identifiers stay outside model context by design. When the customer selects an external AI provider, the required approved context may leave the appliance; therefore MYLO must not claim that nothing ever leaves the local system.