DEV Community: Tahir Almas

New Rules for AI Mental Health Chat: What You Should Expect

Tahir Almas — Fri, 25 Sep 2026 08:33:15 +0000

Originally published at roshni.online

If you've used an AI chat to talk through something difficult, the ground just shifted. Several US states now require these tools to say plainly that they aren't human, to notice when someone is in crisis, and to hand over real help rather than keep talking. It's a low bar. It's also long overdue.

You don't need to follow the legislation to benefit from it. What matters is knowing what a decent AI assistant should do for you, and what it should never pretend to be.

Why lawmakers moved on AI mental health chat

People talk to AI about things they won't say to anyone else. That's not a flaw in the users. A chat window is available at three in the morning, it doesn't look tired, and it never knows your family. For a lot of people that's the first place a hard thought gets said out loud.

The trouble is what happens next. An assistant that's been tuned to be agreeable will agree. One that's been built to keep you engaged will keep you there. Neither instinct is what you need when the conversation turns towards self-harm, and regulators watched enough of those conversations go wrong to start writing rules.

What the new rules actually require

Four duties show up again and again across the laws passed since late 2025.

Say it isn't a person. New York's rules for AI companion models took effect on 5 November 2025. California's SB 243 followed on 1 January 2026. Washington and Oregon have their own versions arriving in 2027. All of them land on the same first requirement: the chat has to make clear you're talking to software.

Notice a crisis. New York's law and Oregon's SB 1546 both expect the system to detect talk of suicide or self-harm and break the normal flow when it appears. Not to counsel. To stop and change course.

Point to real help. Detection without referral is useless, so the same laws attach a duty to surface crisis service details rather than manage the situation inside the chat.

Take extra care with minors. California's SB 243 and Washington's HB 2225 add protections for younger users, including blocking sexual content and prompting breaks so sessions don't run on indefinitely.

Oregon attached a figure to getting it wrong: $1,000 per violation, with a private right of action. Nebraska's LB 525 and Idaho's SB 1297 follow in July 2027.

The four duties that recur across the state laws passed since late 2025.

The rule that changes what these tools can call themselves

Tennessee's SB 1580 takes effect on 1 July 2026 and stops an AI system presenting itself as a licensed mental health professional. That one deserves more attention than it's had.

An assistant can help you order your thoughts before a session. It can help you work out whether what you're dealing with is a mental health question or a legal one, which is less obvious than it sounds when a situation involves both. It can sit with you at an hour when nothing else is open. What it cannot do is hold a licence, carry professional accountability, or take responsibility for your care. Any product implying otherwise is selling you something it doesn't have.

What a good AI assistant should never do

Three behaviours are worth walking away from, whatever the law says.

It shouldn't diagnose you. An assistant that hands you a condition name after nine messages is guessing, and a wrong label can stick for years.

It shouldn't discourage you from seeking a person. If suggesting a professional makes the product look worse, the product is built wrong.

It shouldn't blur into your private records. An assistant you're using to think out loud should be separate from the conversation you have with a professional, so that thinking out loud stays exactly that.

How the assistant on Roshni is set up

The free assistant on Roshni is deliberately built as a starting point rather than a destination. It's clearly an assistant, not a counsellor and not a lawyer. It works in text or voice, in any language you prefer, and it's available around the clock. The conversation is private and kept separate from the chat you have with a professional.

When something needs a person, it says so and hands you over. Roshni runs two tracks, mental health and legal, and the handover matches you to a verified professional by category and rating. You can chat first if that's easier, then move to a video session, and the cost is shown before you book anything. The walkthrough of how the client application works covers the full sequence if you want to see it before signing up.

The assistant is a starting point and a triage step, not the end of the road.

When to stop chatting and ask for a human

There's no clean test, but a few signals are reliable enough to act on.

Ask for a person when the same problem keeps coming back no matter how many times you talk it through. Circling is a sign you need someone who can hold the thread across weeks, not a fresh conversation each time.

Ask when the situation involves anyone else's safety, or when a decision carries legal weight. An assistant can help you understand a document. It can't advise you on what to sign.

And ask when you notice you're using the chat to avoid something rather than work on it. That one's harder to spot from the inside, which is part of why the handover exists.

If someone is in immediate danger, skip all of this. Contact your local emergency number or a crisis line where you live. A chat window is the wrong tool for an emergency and no law has changed that.

What this means if you're choosing a service

The rules give you a checklist you can apply in about a minute. Does it tell you it's AI without being asked? Does it react when you mention harming yourself, or does it carry on as though you'd mentioned the weather? Can you reach a real professional from inside it, and is the price visible before you commit?

A service that clears all four is being run by people who thought about this before a statute made them. One that fails the first question isn't worth the second.

Worth saying plainly: this article is general information about published rules as they stand in September 2026, not legal or medical advice. The laws differ in scope and several are new enough to be untested.

Frequently asked questions

Is an AI mental health chat confidential?

It depends entirely on the service, so check before you type anything sensitive. On Roshni the assistant conversation is private and held separately from your professional consultations. Read the privacy terms of any tool you use, because confidentiality practices vary far more than the marketing suggests.

Can an AI assistant replace therapy?

No, and Tennessee's SB 1580 will stop AI systems from even presenting themselves as licensed professionals from July 2026. An assistant is useful for thinking something through, preparing for a session, or working out who you need. Care is a relationship with a qualified person.

Do these rules apply outside the United States?

These particular laws are US state laws. Other regions are moving on similar ground, and the EU AI Act carries its own transparency duties for systems that interact with people. Roshni is available internationally, and the standards described here are how we think the service should behave regardless of where you are.

What happens when I ask the assistant for a real person?

You're matched with a verified professional on either the mental health or the legal track, based on category and rating. You can start with chat and move to a video session. Session cost appears before you book, and the pricing page lists what each option includes.

Is the AI assistant free?

Yes. Text and voice conversations with the assistant cost nothing, in any language. You only pay when you book time with a human professional.

Related resources

Talk it through, then decide

If something has been sitting with you and you're not sure whether it needs a counsellor, a lawyer, or just an hour of honest thinking, the assistant is a reasonable place to start and it costs nothing. When it turns out you need a person, it will tell you so and connect you to one.

AI Voice Agent Disclosure: What Your Contact Center Must Tell Callers

Tahir Almas — Fri, 25 Sep 2026 08:31:44 +0000

Originally published at ictcontact.com

Short answer: in a growing number of states, yes. If an AI voice agent could pass for a person, several states want a clear notice, and a few want it before the caller says anything. There's no federal standard. The practical fix is one honest sentence at the top of every call.

That sentence is cheaper than the alternative. Building a state-by-state matrix into your dialer sounds precise until a caller ports a number, travels, or forwards their line, and your carefully scoped rule fires in the wrong place. Most teams we talk to land on the same conclusion after an afternoon with the statutes: disclose everywhere, stop thinking about it.

Here's what the rules actually say, and where contact centers keep tripping.

There's no federal AI disclosure rule, and that's the problem

You might expect a single national answer to "do I have to tell people it's a bot?" There isn't one. What exists instead is a patchwork of state laws written at different times, for different worries, with different triggers. Some target deceptive commerce. Some target companion apps aimed at lonely teenagers. A few now reach ordinary customer service.

The result is that two identical calls can carry different obligations depending on where the handset happens to be. For anyone running outbound campaigns across state lines, that's not a theoretical problem.

The states that already ask for proactive notice

Three are worth knowing by name, because they reach normal commercial conversations rather than niche use cases.

Maine is the broadest. Title 10, section 1500-DD covers any person using a bot in trade or commerce, and asks for clear and conspicuous notice where the bot could reasonably be mistaken for a human. The detail that should get your attention: a plaintiff doesn't have to prove consumers were actually misled. The absence of disclosure is the issue, not the damage.

New Jersey is narrower but stricter about timing. Title 56, section 56-18-2 wants clear and conspicuous notification at the start of the interaction, though it's scoped to selling or advertising merchandise and real estate. If you run property or retail campaigns, assume it applies.

Colorado comes at it from a different angle. The Colorado AI Act at section 6-1-1704 attaches disclosure to high-risk consumer interactions, the kind involving employment, finance or education, and lets you off when it would be obvious to a reasonable person that they're dealing with software. That obviousness carve-out is doing a lot of work, and I wouldn't lean on it. Voice synthesis got good enough that "obvious" is no longer a safe bet.

The states that only want an honest answer

Two well-known laws turn out to be gentler than their reputation.

Utah's SB 226, passed in 2025, asks you to disclose that generative AI is in use if the consumer asks, unless you already said so clearly. That's a reactive duty. Your agent needs to answer "am I talking to a robot?" truthfully, which is a prompt design question more than a compliance project.

California's SB 1001, the one everyone calls the B.O.T. Act, reads tougher than it bites. It asks for clear and conspicuous notice, but the duty hinges on an intent to mislead for certain purposes. In practice that narrows it considerably. Plenty of teams assume California is the strict one and Maine is the quiet one. It's the other way round.

Proactive rules and on-request rules, and the single greeting setting that satisfies both.

Where the disclosure actually has to happen

Most teams get the greeting right and then lose the thread. Three moments cause nearly all the trouble.

The handover. A caller told at second zero that they're speaking with an assistant shouldn't have to guess who they're talking to at minute four. When the AI passes the call to a person, say so. It costs a sentence and it prevents the most uncomfortable version of this conversation, which is a customer realising halfway through that they've been confiding in software.

Voicemail and callbacks. This is the quiet one. Your live script gets reviewed and updated. The voicemail drop recorded eight months ago doesn't, and neither does the callback flow that reuses a template written when humans made every call. Go and listen to yours.

Outbound answer detection. Disclose before the pitch, not after. If the first useful thing your agent says is a product name, the notice arrived late.

The greeting is the moment every rule agrees on. The handover and the voicemail drop are where teams slip.

What a compliant greeting sounds like

Keep it plain. "Hi, I'm an automated assistant from Acme. I can help with billing and orders, or put you through to someone." That's it. It names the company, says what it is in words a caller will understand, and offers the exit.

Avoid the clever versions. "I'm Aria, your virtual concierge" is not a disclosure, it's a brand name with a costume on. If a caller could hear your greeting and still reasonably believe a person is on the line, you haven't disclosed anything.

One more thing worth saying out loud: disclosure doesn't hurt completion rates the way people fear. Callers mostly want their problem solved. What annoys them is discovering the deception later, which is exactly the outcome the statutes were written to prevent.

How this sits in ICTContact

The AI voice agent in ICTContact runs on AI Personas, so the disclosure line lives in the persona's opening script rather than being bolted onto each campaign. Set it once and every campaign that uses that persona inherits it. That's the behaviour you want, because the failure mode in every other design is a new campaign launched from a copied template that quietly dropped the notice.

The same applies to the handover. Transfers to a live agent are a routing step you configure, which means the "you're now with a person" line belongs in the routing rule, not in an agent's memory.

If you're still mapping out which parts of your stack would even need changing, the feature overview is the quickest way to see where personas, routing and campaign scripts sit relative to each other. Teams running press-1 style outbound should look hard at their broadcast campaign scripts too, since those were often written long before any AI was involved and tend to be the last thing anyone audits.

Where this is heading

The direction of travel is clear even if the details aren't settled. A separate wave of laws aimed at companion chatbots has been landing since late 2025, and those go much further than disclosure: crisis detection, referral duties, protections for minors. New York's rules took effect in November 2025, California's SB 243 in January 2026, and Oregon, Washington, Nebraska and Idaho have all queued up obligations for 2027.

Contact centers aren't companion apps, and most of that won't apply to you. But legislatures borrow language from each other, and the phrase that keeps surviving every draft is the simple one about telling people they're not talking to a human. Build for that and you'll be fine.

One caveat, stated plainly: this is a summary of published rules as they stand in September 2026, not legal advice. Scope and wording differ between states, several of these laws are new enough that nobody has tested them in court, and your counsel should see anything you're about to ship.

Frequently asked questions

Does an AI voice agent have to say it's AI on every single call?

Under the proactive rules, yes, where the agent could be mistaken for a person. Maine's law doesn't require anyone to show they were actually misled, so silence is the risk rather than confusion. Disclosing on every call is simpler than deciding call by call.

Is a disclosure in the terms and conditions enough?

No. The laws that specify timing want the notice in the interaction itself, and New Jersey's says at the start of it. Nobody reads terms before answering the phone, and the statutes were drafted by people who know that.

What about calls to customers outside the United States?

Different regimes apply, and some are stricter. The EU AI Act carries its own transparency obligations for systems that interact with people. If you run international campaigns, treat the US patchwork as your floor rather than your ceiling.

Do we need to disclose when a human agent uses AI assistance in the background?

Generally no, because the caller is speaking with a person. The line matters when AI is the one holding the conversation. That said, if your setup has AI speaking directly to the caller at any point, that part needs the notice.

Does disclosure hurt answer or completion rates?

Less than teams expect. Callers who get their issue resolved don't generally mind how. The damage comes from a customer working out mid-call that they were misled, which costs more than any measurable dip at the greeting.

Related resources

Get your disclosure set up once

If your AI agent is already live, the fastest useful thing you can do this week is listen to one recording from every campaign type you run, including the voicemail drops. You'll find the gap in about twenty minutes. When you're ready to fix it in one place rather than campaign by campaign, the ICTContact feature set shows how personas and routing rules carry the notice for you.

Florida Just Wrote the AI Questions Your Assessment Platform Has to Answer

Tahir Almas — Tue, 22 Sep 2026 19:40:47 +0000

Originally published at ictlms.net

On 16 September the Florida State Board of Education approved statewide rules on AI in education, with institutions given until 1 July 2027 to adopt and implement policies. Buried in the requirements is a list that reads less like education policy and more like a procurement questionnaire for anyone selling assessment software.

The requirement that matters to assessment

The policies have to address academic integrity, and the reporting is specific about what that means in practice: plagiarism, when students are permitted to use AI, how teachers can verify student work, and when students must disclose AI use.

Read those as four questions somebody will eventually put to you in writing.

The first one breaks most setups immediately. "When are students permitted to use AI" is almost never a single answer for an institution. It varies by course, by assessment type, sometimes by individual question. If your platform expresses that as a paragraph in a handbook rather than a setting attached to the paper, you cannot demonstrate compliance and you cannot enforce it either.

The second is the one we have written about before and will keep writing about. The rules ask how a teacher verifies work. They do not ask for a detector score, and that is the right instinct, because a probability output is not evidence anybody can reason about. Drafting history, an oral follow-up, a supervised tier for high-stakes papers: these produce something a human can examine and a student can contest.

The third sounds trivial and is not. Disclosure only functions if there is somewhere to record it at the moment of submission, and if that record stays attached to the attempt when it goes into an appeal eighteen months later.

About whether this applies to you

Here we should be straight with you, because the coverage is not consistent. Headlines describe the rules as covering K-12 schools and colleges. Body copy in the same reporting describes the obligations landing on school districts and charter school boards. We could not open the state's own release to settle it, so we are not going to assert a scope we have not verified.

What is not in dispute: the rules were approved on 16 September, the deadline is 1 July 2027, and the academic integrity requirements above are part of them. If you run assessment in Florida, read the rule text rather than the coverage, including ours.

The scope question matters less than it appears, for two reasons. Dual enrolment already pushes school district policy into college courses, so the boundary is porous in practice. And more importantly, requirements like these do not stay in one state. They become the template the next procurement committee works from, wherever that committee sits.

What an assessment platform should be able to produce

If you strip the policy language away, all four questions reduce to one: can you show your working, months later, to somebody who is unhappy?

Concretely, for any given attempt on a smart online exam, that means being able to answer:

What was permitted on this paper. Not what the institution's policy said in general, but the rule that applied to this assessment, on this date, as the student saw it.
What the student declared. Captured at submission, not reconstructed afterwards from memory or email.
What evidence exists beyond a score. If AI assisted the marking, what the model produced, what a human changed, and who signed it off.
Who saw what, and when. The access trail, because an appeal frequently turns into an argument about process rather than about the answer itself.

None of that is exotic. It is ordinary record keeping applied to a process that has historically been casual about it, on the reasonable assumption that nobody would ever ask.

The part vendors should sit with

The broader theme across the reporting is a distrust of opacity. Rules about undisclosed monitoring and about grading students without anyone being able to see how, aimed at exactly the kind of system that produces a number and declines to explain it.

For anyone building AI into assessment, including us, that sets the bar clearly enough. A grading model that cannot show its reasoning, cannot be overridden on the record, and cannot be explained to a student is going to fail this kind of policy test regardless of how accurate it is. Accuracy was never the thing being asked about.

Frequently asked questions

Is this law now?

The rules were approved by the State Board of Education on 16 September 2026, with a compliance deadline of 1 July 2027. That is an adopted rule rather than a proposal, but check the rule text for exactly who it binds before acting on a summary.

Does it ban AI grading?

Nothing in the reporting suggests a ban. The direction of travel is against grading that nobody can inspect. Disclosed, reviewable, overridable AI assistance is a different proposition from an unexplained score.

We are not in Florida. Why should we care?

Because these requirements are the ones your own committee will copy. It is far cheaper to be able to answer the four questions now than to retrofit the records once somebody asks.

What if our policy already covers AI use?

Most do, at the level of a written statement. The question these rules raise is whether the statement is connected to anything the system enforces or records. Those are very different things.

How long should assessment records be kept?

Long enough to outlast your appeals window, which is usually longer than the default retention in the platform. Work backwards from the longest appeal route a student actually has.

The Robocall Consent Ruling Everyone Is Quoting Was Decided on a Phone in the Mississippi

Tahir Almas — Tue, 22 Sep 2026 19:37:22 +0000

Originally published at ictbroadcast.com

A ruling out of Maryland is being passed around as though prior express consent just got much easier. The line people are quoting is that a consumer consents to the call, not to the prerecorded voice used to make it. Before you touch your consent capture, read what the court actually decided. It denied class certification because the plaintiff threw his phone into the Mississippi River.

The case

Smith v. ExamWorks, 2026 WL 2823260, decided in the District of Maryland on 21 September 2026, case number 8:21-cv-02746-PX. Filed back in October 2021, it was a two-count class action against GEICO and ExamWorks over non-emergency prerecorded calls placed by a GEICO vendor to schedule independent medical examinations.

The court refused to certify the class. The reason given most attention in the write-ups is adequacy: to represent a class you have to show you are in the same position as its members, and this plaintiff was not, because at some point during the litigation he destroyed the single most important piece of evidence. With the handset gone, the defence could not examine it to establish who had been messaging him, what he had been doing, or even that the calls had landed on that phone at all.

Where the consent language comes in

Along the way the court made some observations that would help callers if they stand. One is that consent can be conveyed by conduct, so handing a business your phone number can itself amount to prior express consent. The other is the reading being quoted everywhere: that the statutory phrase about a call made with prior express consent attaches to the call, not to the use of a prerecorded voice. On that reading a consumer does not have to agree to the technology, only to being contacted.

That is genuinely interesting, and it may matter later. It is also not what the case was decided on. The certification denial did not rest on it, which is the textbook definition of a remark a later court is free to ignore.

The lawyer who broke the story is blunt about it himself. His write-up describes the court's other findings as likely driven by its irritation at the destruction of evidence. When the person arguing your side says the reasoning was coloured by the plaintiff's behaviour, that is a signal about how much weight it will carry.

Why we are not changing anything, and nor should you

Start with the fact that the same district pointed the other way six months ago. A March 2026 decision in the District of Maryland suggested consent has to reference the regulated technology. Two orders, one courthouse, opposite directions, and no appellate ruling tidying it up. A split like that is a reason to sit still, not to move.

Then there is geography. A call center software operation places calls into every state, and the plaintiff picks the forum. A helpful reading in Maryland does nothing for you in a district that has never considered the question.

State law is the third problem, and the one people forget. Florida, Oklahoma and Washington run their own telemarketing statutes with their own consent standards and their own private rights of action. A federal court's reading of the TCPA does not move any of them. Plenty of operators who are clean federally have been sued under a state statute instead.

And this is also single-source for now. One specialist blog has written it up, in two posts on the same day. That is not a criticism of the reporting, it is a statement about how much confirmation exists. Before rebuilding a consent flow on the strength of it, wait for other lawyers to read the order.

What is actually worth doing this week

The useful lesson in this case is not about consent at all. It is that the defence won because it could point at missing evidence, and the plaintiff lost because the record was gone.

That cuts both ways, and your side of it is the consent file. For every number you dial you want to be able to produce where it came from, what the person was looking at when they gave it, the exact wording they agreed to, and the timestamp. Not a flag in a column saying consent equals yes, but the underlying record.

Three things make that real in a dialling platform:

Store the form as it appeared, not just the answer. Consent language changes. If you cannot show what the page said in March, you cannot prove what somebody agreed to in March.
Keep the provenance with the record. Numbers arrive from web forms, imported lists, partner feeds and inbound calls, and those carry very different weight. Merge them into one field and you have thrown away the distinction a court will ask about.
Retain long enough to survive the limitation period. A four year old claim needs a four year old record. Retention policies written for storage cost tend not to account for that.

None of that depends on how this consent question resolves. It is what turns a lawsuit into an early exit regardless of which way the reading goes.

Frequently asked questions

Does this mean giving out my number is now consent to robocalls?

No. One district court suggested it might be, in a case decided on other grounds, and another judge in the same district suggested otherwise earlier this year. Nothing has changed about what you are required to do.

Is the ruling binding anywhere?

District court decisions bind nobody, not even other judges in the same district. They carry persuasive weight, and a point the decision did not rest on carries less of it again.

Should we stop asking for technology-specific consent?

No. Asking somebody to agree to prerecorded or automated calls costs you a line of text and removes an argument. Dropping it to chase a favourable reading that might not survive is a poor trade.

What about informational calls like appointment scheduling?

That was the setting here, and informational calls have always had a different consent posture from marketing. The distinction is worth keeping clear in your campaign configuration, because it decides what a revocation covers.

How long should consent records be kept?

Long enough to cover the limitation period for every claim you could face, federal and state, which is longer than most retention defaults. Work backwards from the longest one that applies to you.

Salesforce Went Down for Ten Hours and You Could Not Even Open a Support Ticket

Tahir Almas — Mon, 21 Sep 2026 07:23:36 +0000

Originally published at ictcrm.com

On 16 September, Salesforce instances stopped answering across every region. Logins failed, APIs failed, orgs were unreachable, and customers could not raise a support case because the Help portal was caught in it too. It lasted most of a working day, it happened on the opening day of Dreamforce, and the root cause field on the incident record is still empty.

What the record actually says

Rather than rely on the write-ups, we pulled the vendor's own status record. Incident 20004433, service key coreService.

The first public update landed at 08:45 UTC, describing severe delays, intermittent errors and an inability to access services across multiple instances in all regions. At 09:10 UTC Salesforce named the mechanism: requests were stalling while waiting on a response from an internal login service, and that was consuming the available server resources. Telemetry was healthy again from 15:26 UTC, and the incident was marked resolved at 18:59 UTC.

That is roughly six and three quarter hours of degraded service and ten hours and fourteen minutes from first notice to all clear. If you have seen other numbers quoted, that is why. Different write-ups measured different things, and some picked the window from the first report to resolution while others used the impact window.

The count of affected instances moved more than once, and was revised down the following day when Salesforce found sandboxes had not been affected after all. That is a reasonable correction to make. It is also a reminder that the number you read during an incident is provisional.

The part that should bother you

Not the downtime. Everything fails eventually, and a vendor at that scale will have better uptime over a year than most companies manage on their own hardware. Be honest about that.

The part that should bother you is that the rootCause and actionPlan fields on that incident are still null days later. There is a description of the symptom and no published explanation. If a customer of yours asks why their orders did not go out on the sixteenth, everything you can tell them is a paraphrase of somebody else's status page.

The second part is that the support portal went down with the product. The escalation path and the thing that broke shared a dependency, which is the sort of design detail nobody notices until the day it matters.

What this does and does not prove about self-hosting

It would be easy, and dishonest, to turn this into a claim that self-hosted CRM software does not go down. It does. Your disk fills up, your certificate expires, somebody applies an update on a Friday. Run your own infrastructure badly and you will beat this outage for downtime without much effort.

What changes is who owns the failure. On your own deployment you can restart the thing at three in the morning instead of refreshing a status page. Your logs are yours, so the explanation exists whether or not anyone chooses to publish it. And the blast radius is you, rather than every customer of one vendor in every region at the same moment.

That last one cuts both ways and it is worth saying plainly. A shared outage means nobody notices it for you. No status page lights up, no account manager calls. If you self-host and nobody is on call, you find out when a customer tells you, which is worse than any of this.

Three questions worth asking your own setup

Whichever way you deploy, this incident exposes questions that are cheap to answer now and expensive to answer during an outage.

Does your escalation path share a dependency with the thing it escalates? Salesforce customers could not open a ticket because the ticket system needed the login service that had failed. If your monitoring, your status page or your on-call paging runs on the same infrastructure as the application, you have the same problem in miniature.
Could you answer a customer asking what happened? Not could you repeat a vendor statement, but could you look at something you control and say what broke. If the answer is no, that is a decision you have already made without noticing.
What does your team do for six hours with no CRM? The useful answer is not a workaround invented on the day. It is knowing in advance whether calls can still be logged, whether orders can be taken on paper, and who reconciles it afterwards.

The wider point about dependency

A single internal login service stalling was enough to make a platform unreachable everywhere at once. Not a data centre fire, not a cable cut. One component, under load, holding requests open until the resources ran out.

Every system has a component like that. The difference between deployment models is not whether the weak point exists, it is whether you are allowed to look at it, and whether you are the one who gets to decide how fast it comes back.

Frequently asked questions

How long was the outage exactly?

The vendor's incident record shows the first update at 08:45 UTC and resolution at 18:59 UTC on 16 September, with telemetry healthy from 15:26 UTC. That gives about six and three quarter hours of impact and ten hours overall. Quoted figures vary because different sources measured different windows.

Was customer data lost?

Nothing in the incident record indicates data loss. This was an availability incident, not a data one, and it should not be described as a breach.

Does an SLA credit cover this?

Credits are usually a percentage of a monthly fee and rarely resemble the cost of a lost day of selling. Read yours before you rely on it, and check whether claiming is automatic or whether you have to file within a window.

Is self-hosted CRM more reliable?

Not automatically, and anyone telling you otherwise is selling something. It is more controllable. Whether that turns into better availability depends entirely on whether you staff it.

What is the cheapest improvement we can make this week?

Move your status and alerting off the same infrastructure as the application, and write down what the team does during an outage. Neither costs much, and both are worth more than an architecture debate you will not finish.

No, the FCC Has Not Changed the Revoke-All Rule. The Vote Is on 30 September

Tahir Almas — Mon, 21 Sep 2026 07:20:04 +0000

Originally published at ictdialer.com

If you read last week that the FCC has changed the TCPA revoke-all rule, you read something wrong. The document everyone is quoting is a draft, circulated on 9 September for a vote at the Commission's open meeting on 30 September 2026. Until that vote happens, the rule you have to follow is the one you are already following.

How to check this yourself in ten seconds

Open the draft, FCC-CIRC 2609-05 in CG Docket No. 02-278, and look at the header. It reads:

Adopted: [ ] Released: [ ]

Empty brackets. The FCC fills those in when a document is actually adopted and released. The cover text says the item "has been circulated for tentative consideration by the Commission at its September 30, 2026 open meeting", and adds that the Commission's ultimate resolution may differ from what the draft says.

That has not stopped a fair number of write-ups describing it as adopted, or as a final rule issued on 9 September. If you are planning a compliance change off one of those summaries, you are planning off a document that could still be edited or voted down.

What it would actually change

Today, under 47 CFR 64.1200(a)(10), any reasonable method of revoking consent counts. Somebody says "take me off your list" to an agent, replies with a word you never anticipated, or writes it on a form, and it counts. That is a hard thing to build for, because you are effectively promising to catch revocation in any form it arrives.

The draft would let you designate the channels. A key press during the call, a reply keyword, or a phone number or web page you nominate. Honour revocations arriving through those and you have met the duty. The draft names the keywords it has in mind: stop, quit, end, revoke, opt out, cancel and unsubscribe.

It would also let you scope revocation for informational calls. Someone opting out of payment reminders would not automatically be opted out of delivery notifications. Marketing does not get that treatment, and a revocation there still stops all future telemarketing robocalls and texts from you.

The ten business day processing window stays as it is.

The dates that matter

Here is the part worth putting in your calendar. If the draft is adopted, the new rules take effect about 30 days after they appear in the Federal Register. Not January. That would supersede the 31 January 2027 revoke-all date that most teams have been building toward, and pull the work forward by months.

So the risk is not that this passes. The risk is that you treated 31 January as the deadline, and the real one lands in November.

What to do while it is still a draft

Keep building for the rule as it stands, because that is the rule you are judged against today, and because the looser version might not arrive. Someone replying "please stop calling" in a form you did not anticipate still revokes consent right now.

But design so the change is configuration rather than a rewrite. Three things make the difference in an auto dialer:

Record where each revocation came from. If channel starts to matter legally, you want a field saying whether it arrived by key press, by keyword, through the website or from an agent. Retrofitting that onto historical records is the expensive version of this project.
Tag suppression entries by campaign category. If scoping arrives, you need to be able to say this person opted out of reminders but not alerts. A single global do-not-call flag cannot express that, and splitting it later means guessing at intent you never captured.
Handle the keyword list as data. The seven words in the draft are not the seven you will end up with, and they are not the same across every state. A list you can edit beats a list compiled into your message handler.

None of that is wasted if the draft fails. Knowing how a revocation reached you and which campaign it applied to is useful record keeping regardless, and it is exactly what you want in front of you if somebody sues.

The further notice, which is a separate thing again

Bundled with the Report and Order is a Further Notice of Proposed Rulemaking, which is only a set of questions. It asks about shortening the processing window below ten business days, about ending one-way texting where a caller sends messages from a number that cannot receive replies, about whether an automated revoke-all method should be mandatory, and about how consent travels between affiliates and divisions of the same company.

That last one is the one to watch. If you run several brands from the same platform, the answer decides whether an opt-out from one reaches the others.

Frequently asked questions

Is the revoke-all rule in force right now?

The underlying requirement in 64.1200(a)(10) is in force. The broader revoke-all provisions had been delayed to 31 January 2027, and this draft would replace them before that date arrives. Nothing in the draft itself is enforceable today.

How will I know if it passes?

The Commission votes at the 30 September open meeting. If adopted, a released version appears with real dates in those brackets, then publication in the Federal Register starts the clock. Watch the docket number rather than the commentary.

Should we stop honouring revocations that arrive by other routes?

No, and not even if this passes. The draft would let you designate channels, not ignore people. A recorded request you chose not to act on is the kind of fact that reads badly in front of a court, whatever the rule technically permits.

Does this affect texts as well as calls?

Yes. Robotexts sit under the same consent and revocation framework, which is why the keyword list matters so much. The further notice also asks specifically about one-way texting.

What about state rules?

They stack on top and none of this touches them. A mini-TCPA can impose its own consent and revocation requirements with its own private right of action, so federal compliance on its own is not a defence.

OCR Did Not Fine Ambry Over How Documents Moved. It Fined Them Over Who Could Reach Them

Tahir Almas — Sat, 19 Sep 2026 05:57:09 +0000

Originally published at ictfax.com

On 17 September the HHS Office for Civil Rights announced a $700,000 settlement with Ambry Genetics over a phishing breach affecting 225,370 people. Read the findings and something stands out. OCR did not cite a single provision about how protected health information travelled. It cited who could reach it, and whether anyone had ever checked.

What actually happened

An attacker phished an employee's email credentials and had access to that account from 22 to 24 January 2020. Ambry filed its breach report on 22 March 2020. The exposed data included names, addresses, dates of birth, driver's licence numbers, diagnosis and treatment information, medications, and some Social Security numbers. The resolution is a settlement with a corrective action plan rather than a civil money penalty, and OCR monitors it for two years.

It is worth being precise about this, because it is easy to file it under the wrong heading. This was an account compromise. Email appears as the way in, not as the channel the records were sent over. Nobody was penalised for a misdirected document.

The three findings

Two of the three are identity controls. Unique user identification under 45 CFR 164.312(a)(2)(i), meaning every person who touches systems holding ePHI gets their own identifier. Termination procedures under 164.308(a)(3)(ii)(C), meaning access ends when someone leaves or no longer needs it. The third, risk analysis under 164.308(a)(1)(ii)(A), is the one that keeps turning up in every enforcement action OCR publishes.

The corrective action plan follows the same shape: a proper risk analysis, a risk management plan, Security Rule policies that get reviewed, unique user identification implemented across every system holding ePHI, and workforce training on all of it.

Every system holding ePHI includes the fax server

That phrase is where this stops being somebody else's problem. A fax server holds ePHI in more places than most inventories admit. The spool directory while a job is queued. The rendered image after conversion. Delivery receipts that carry the recipient number and often the patient identifier. The archive, which in a lot of deployments goes back years because nobody set a retention rule.

If your last risk analysis listed the EHR, the imaging system and the file shares, and treated fax as a peripheral, that is exactly the gap OCR describes when it says an analysis was not compliant. We wrote about the analysis half of this in more detail recently, so this post stays on the identity half.

Where the shared login survives

Fax is unusually good at hiding shared credentials, because the workflow is physical. Somebody walks to a machine. The machine has one account. Everyone uses it.

The department login is the obvious one. Records, radiology, front desk, one password, often written down near the device because thirty people need it. Then the multifunction printer, which usually holds a single scan-to-fax service credential shared by everyone who walks up to it. Then the integration account, where the EHR or billing system sends through one API user, so every outbound fax carries the same author no matter who actually requested it.

The fourth is the leaver. HR closes the directory account, and the fax mailbox, the routing rule and the shared inbox membership all carry on working. That is 164.308(a)(3)(ii)(C) almost word for word.

Shared inboxes are fine. Shared credentials are not

This distinction gets lost and it matters. A shared inbox that several named people can open is normal and sensible, and nothing in the rule forbids it. What the rule asks is that the system can say which named person did a given thing. One set of credentials that thirty people type destroys that, and it destroys it permanently, because you cannot reconstruct the answer later from logs that only ever recorded a department.

At the device, card or PIN release solves it: the printer authenticates the person and passes that identity to the fax server, so the log names a human. For integrations, the service account authenticates as itself while the request carries the requesting user, which is a small change in how the API call is made and a large change in what the audit trail is worth.

The test that takes five minutes

Pick a fax your organisation sent six months ago and pull the record. If it names a person, you are in reasonable shape. If it names a department, a printer or an integration, you have found the same finding OCR cited, and you found it before an investigator did.

Do the same for a leaver. Take someone who left three months ago and check whether their fax mailbox still exists, whether inbound routing still points at them, and whether anyone would notice if a document arrived there tomorrow.

The stakes are being raised, slowly

On the same day as the Ambry announcement, Senators Ron Wyden and Mark Warner reintroduced the Health Infrastructure Security and Accountability Act. It would have HHS set mandatory minimum security standards rather than addressable ones, require annual stress tests and independent audits, and, notably, require an annual written attestation signed by the chief executive and the security officer.

It is a bill, not a rule, and reintroduced bills often go nowhere. But the attestation idea is worth sitting with. Signing your name to a statement about systems nobody has inventoried is a different proposition to filing a report, and unexamined fax infrastructure is precisely the sort of thing that makes a signature uncomfortable.

Frequently asked questions

Does HIPAA actually ban shared accounts?

It does not say so in those words. It requires unique user identification as a required implementation specification, which in practice means the system must be able to attribute activity to an individual. A shared credential makes that impossible, which is why it keeps appearing in enforcement findings.

We use a shared fax inbox for a whole department. Is that a problem?

Not by itself. The question is whether each person signs in as themselves before they open it. A shared mailbox with named access is fine. A shared password is the problem.

What about the multifunction printer in the corridor?

That is usually the weakest point, because the device holds one service credential and the walk-up workflow has no sign-in. Card or PIN release at the panel is the normal fix, and it needs the fax server to accept the identity the device passes rather than logging the device itself.

How far back does the archive need to be covered?

As far back as it goes. Old faxes are still ePHI, and an archive that nobody has applied a retention rule to is both a risk analysis finding and an access control one. Deciding a retention period is often the cheapest single improvement available.

Is $700,000 typical for this kind of case?

Settlement amounts vary a great deal with the size of the organisation and how it engaged with the investigation. The number is less instructive than the findings, because the findings tell you what OCR looked at, and those recur far more predictably than the penalties do.

The FCC Wants 42 Cents on the Dollar in Q4. Your October Invoices Are Already Late

Tahir Almas — Sat, 19 Sep 2026 05:52:21 +0000

Originally published at ict.vision

The FCC has proposed a Universal Service Fund contribution factor of 42.0% for the fourth quarter of 2026, up from 38.8% in Q3. That is a record high for the second quarter running. It was released on 14 September in Public Notice DA 26-946 under CC Docket No. 96-45, and unless the Commission acts within fourteen days it is deemed approved. Your October invoices carry it.

What the number actually is

The contribution factor is the percentage of your assessable interstate and international end user revenue that goes to the Universal Service Fund. At 42%, every assessable dollar owes 42 cents. Intrastate revenue is not assessable, which is why two providers with identical turnover can owe very different amounts.

On a thousand dollars of assessable revenue the quarter-on-quarter move is 32 dollars. That sounds small until you multiply it by a book of business and remember it lands on one line of every affected bill, in a quarter you have probably already quoted.

The figure is after the offsets, not before them

Here is the part that gets missed. The Office of Managing Director directed USAC to apply $69 million of unused E-Rate funds and $56 million from Rural Health Care against the quarter. 42.0% is what came out the other side. Without those the proposed factor would have been higher still.

That matters for planning, because one-off offsets are exactly that. You cannot build a 2027 forecast on the assumption that unused money will keep showing up to soften the number.

Why this lands harder on wholesale and white-label

If you sell direct, you reprice one set of invoices. If you run a wholesale or white label platform, the change has to travel. Your resellers bill their own customers under their own brand, on their own cycles, often with their own billing systems. They cannot pass through what they have not been told about.

The failure mode is predictable. A partner bills October at the old rate, notices in November, and then has to decide between eating the difference or sending a correction to customers who thought the price was settled. Either way it becomes a support conversation, and eventually it becomes your support conversation.

You can recover it. You cannot mark it up

Truth-in-Billing lets you recover your contribution from customers as a separate line. It does not let you treat that line as a margin opportunity. A recovery charge noticeably larger than the factor applied to the assessable portion of the bill is one of the clearest things an enforcement review can spot, because anyone can do the arithmetic from a copy of the invoice.

Two related habits are worth checking while you are in there. Label the line so it is obviously a regulatory recovery rather than a government-mandated tax, and apply the factor only to the assessable portion rather than to the whole bill.

The exemption certificates nobody chases until it hurts

Selling wholesale to another carrier is generally not assessable at your level, because they contribute on the retail revenue instead. That relief depends on having their exemption certificate on file. No certificate, and the revenue is treated as assessable at your end, which means you pay a contribution you already priced away.

At 42% the cost of a missing certificate is materially higher than it was two quarters ago. Now is a sensible time to go through the file and find the gaps, rather than discovering them during a true-up.

One more thing on the calendar

Separately, comments on the FCC's proposed Robocall Mitigation Scorecard are due on 22 September, with replies on 2 October, under DA 26-932 in CG Docket No. 26-239. The proposal scores retail voice providers and, as drafted, leaves pure wholesale and intermediate providers out of the scoring. If you sit in that middle layer, the scope language is worth reading closely rather than assuming it does not apply to you.

What to do this week

Work out your own pass-through at 42% on assessable revenue only. Tell your resellers and platform partners in writing, with the date the change applies and the wording you would like on the line item. Check that your billing platform lets you change the factor per quarter without a code release, because it will change again in January. And pull the exemption certificates.

None of this is difficult. It is just time-sensitive, and the window between a public notice and a billing run is shorter than it looks.

Frequently asked questions

Is the 42% figure final?

No. It is proposed. Under the standing process it is deemed approved if the Commission does not act within fourteen days of release, which puts the effective date around 28 September for a quarter starting 1 October. Treat it as the planning number and confirm before you bill.

Which revenue is assessable?

Interstate and international end user telecommunications revenue. Intrastate revenue is not. Getting the split right matters more at 42% than it did at 30%, and a jurisdictional allocation that was roughly right a few years ago is worth revisiting.

Do resellers contribute directly?

It depends on who reports the retail revenue. Where the underlying carrier contributes on that revenue, the reseller generally does not contribute again on the same dollars, which is what the exemption certificate documents. Without the certificate the carrier has to assess it.

Can we just absorb the increase instead of passing it through?

You can. Plenty of providers do on competitive accounts. The obligation to contribute sits with you either way, so absorbing it is a margin decision rather than a compliance one.

How much notice do our partners need?

More than you think, because their billing cycles are not yours. Anything that has to reach an end customer before 1 October needs to be with the partner in September, not on the first working day of the quarter.

There Was No Awesome List for Asterisk or FreeSWITCH, So We Opened 107 Repos and Built Two

Tahir Almas — Sat, 19 Sep 2026 05:39:13 +0000

Originally published at ictinnovations.com

The awesome.re directory carries more than 600 curated lists. One of them covers real-time communications broadly, and it is a good list, but nothing on that directory is dedicated to Asterisk, and nothing to FreeSWITCH. So we built both and published them this month: Awesome Asterisk with 50 entries and Awesome FreeSWITCH with 57. Every repository was opened and read before it went on the list.

Why the gap was worth filling

If you have gone looking for FreeSWITCH tooling recently, you have probably landed on the rts-cn list. It has not been touched since 2022, and a good share of what it points at stopped moving years ago. That is worse than having no list, because you spend an afternoon evaluating something before you notice the last release predates the pandemic.

Asterisk is in better shape, but the good stuff is scattered across GitHub topics, old forum threads and a handful of blog posts. Nobody had pulled it into one place and then gone back to check it was all still alive.

So the promise of these two lists is small and specific. Nothing on them is dead. That is the whole pitch, and it is the only part that takes real work.

Four gates, and what they cost

Every candidate had to clear the same four checks, and quite a few well known names did not.

The twelve month rule was the expensive one. It cost us node-esl, which plenty of people still reach for on the FreeSWITCH side, and mod_bcg729. On the Asterisk side it took out Browser-Phone, which still has live issues but no commit since November 2024, and soup, dormant since 2022. The archived tiredofit/docker-freepbx went the same way.

We wrote the rejections down in the repository rather than quietly dropping them, so nobody has to repeat the check. If a project wakes up, it goes back on.

Source available is not open source

Gate three caught PearlPBX2, a Django front end for Asterisk that somebody suggested the day after the Asterisk list went up. Active, real, commits that week. It was on PolyForm Shield 1.0.0, which lets you read and run the code but not build something that competes with the author. That is a perfectly reasonable licence. It is not an open source one, so the entry did not go in.

We said so publicly and explained exactly which clause was the problem. The author relicensed to AGPL-3.0 and tagged a release the next day, and the project is on the list now. Telling somebody why they were left out turns out to be far more useful than leaving them out quietly.

Read the licence file, not the badge

The VoipMonitor sniffer is a good example of why the check has to be manual. GitHub reports no licence on that repository, because there is no LICENSE file in the root. The README states GPL-2.0 plainly. Anyone skimming the sidebar would drop it. It is listed, with that wrinkle written into the entry so you are not surprised later.

The reverse trap is just as common. A repository can carry an MIT badge from a template while the actual terms live in a COPYING file that says something else entirely.

What the lists cover

The sections follow the parts of a deployment you actually have to solve rather than package categories. Event Socket and ARI libraries, streaming call audio, the speech engines people put behind it, SIP proxies, RTP, monitoring, security, endpoints, billing. The FreeSWITCH list has a Platforms section for projects where FreeSWITCH is the engine under something larger, which is how a lot of people meet it without knowing.

Twelve of the 107 entries are ours, including the projects we maintain such as ICTCore, ICTFax and pbx-mcp. A Footnotes section at the bottom of each list names every one of them. They are held to the same bar as everything else and you can challenge any of them in an issue.

Readers found things faster than we did

Within three days of the Asterisk list going up, one reader pointed out that the asteriskdocs book site had stopped resolving. He was right, the domain does not answer at all now, which made it a dead link on a list whose entire pitch is that nothing dead went in. Entry pulled.

Another reader flagged AVA, an AI voice agent for Asterisk with 1.2k stars that we had somehow missed. That one says more about how we searched than about the project, and it was added the same day. A FreeSWITCH reader asked for FS PBX, the Laravel and Vue rebuild of the FusionPBX interface. Checked, Apache-2.0, actively committed, added.

That pattern is the point of publishing a list rather than keeping notes. Three people found four things in a week that we would not have found on our own.

What we would like back

Gaps, mainly. Anything outside the usual English language repositories, because that is where our search was weakest. Open an issue or a pull request on either list, one entry per pull request. If you think one of our own entries does not earn its place, say so and we will drop it.

Both lists are CC0, so you can copy them, fork them or lift entries straight out without asking, and both pass awesome-lint. If you are working on the voice AI side, our write-up on what six voice agent releases taught us about AudioSocket and barge-in covers a lot of what sits behind those entries, and the caller side benchmark measures the things the READMEs never mention.

Frequently asked questions

What makes a list awesome rather than just a bookmark folder?

The awesome.re guidelines set the bar: a real theme, a description on every entry, contribution guidelines, and a maintainer who prunes. The pruning is the part most lists skip, and it is the part that decides whether the list is worth anything in two years.

How do you decide when a project is dead?

No commit in the last twelve months, or an archived repository. It is a blunt rule and it does remove a few stable, finished libraries that simply need no changes. We accept that cost, because the alternative is judging case by case and quietly letting the list rot.

Why are your own projects on the list at all?

Because leaving them off would be its own kind of dishonesty, and because they meet the same test. What matters is that you can tell which ones they are, so each list has a Footnotes section naming all of them.

Can I submit a commercial or source available project?

Commercial is fine if the project itself is open source under an OSI approved licence. Source available licences such as PolyForm, BUSL or SSPL do not qualify, however good the software is. If you relicense, reopen the issue.

Will these be submitted to the main awesome directory?

That is the plan. The directory asks that a list be at least 30 days old first, so Awesome Asterisk becomes eligible in early October and Awesome FreeSWITCH a couple of weeks later. Waiting is not a hardship, since it gives both lists a month of real maintenance to point at.

Where do I report a broken link?

An issue on the relevant repository is the fastest route. Dead links are treated as bugs rather than suggestions, and they get fixed the same day where we can.

A German Court Says Your Support Bot Speaks For You

Tahir Almas — Wed, 16 Sep 2026 20:59:47 +0000

Originally published at ictdesk.net

A clinic put a chatbot on its website to book appointments and answer questions. Someone asked whether its doctors were specialists. The bot said yes and named two qualifications that neither doctor actually held. Nobody typed that claim. The model produced it.

On 12 May 2026 the Higher Regional Court of Hamm decided that the clinic was on the hook for it anyway, in case 4 UKI 3/25. If you run live support software with any AI answering in front of customers, that is the ruling to read this month.

What the court actually decided

The reasoning is short and uncomfortable. The chatbot is not an independent third party. It is a tool the operator chose, deployed and controls. So its statements are attributed to the operator directly, and the misleading answer counted as an unfair commercial practice.

The court went further on the point most teams would have leaned on. Liability applies even where the model hallucinates, and even where the operator configured things carefully. The reason given is that the operator defines the bot's scope and can change it at any time. That control is what makes the words yours.

Three defences went in. None came out.

Worth keeping in proportion: this is a German higher regional court, and an appeal to the Federal Court of Justice was admitted, so it may yet move. A related Munich decision pushed the same way on AI generated summaries. My view is that you plan as though it stands, because the cost of being wrong is asymmetric and the fix is cheap.

Why this is different from the disclosure rules

We wrote about the EU AI Act transparency obligation when it landed, and it is easy to file this ruling in the same drawer. It does not belong there.

Disclosure is about telling people they are talking to a machine. This is about being bound by what the machine then says. You can satisfy the first perfectly, with a clear "you are chatting with an AI assistant" banner, and still lose on the second, because the visitor was told it was a bot and was still misled about a qualification, a price or a refund.

Put bluntly, the banner protects the user's right to know. It does not protect you.

Scope is the control you actually have

You cannot make a language model stop inventing things. You can decide which subjects it is allowed to speak about unaided, and that is where the work belongs.

The way I would structure it is three lanes. Some topics the bot can answer freely, because a wrong answer is cheap and correctable. Some it may answer only by quoting a source it retrieved, and it should show that source in the reply. And some it must never answer, only route.

The third lane is the one that matters legally. Everything a customer could act on belongs there.

The sorting rule is not difficulty. It is reliance. Opening hours are safe not because they are simple but because nobody structures their affairs around them. Anything touching credentials, entitlements, money or contract terms goes in the escalation lane no matter how confidently the model handles it in testing.

Pricing sits awkwardly in the middle, and I would put it in the quote-only lane rather than the free lane. A bot that says "our Business plan is 49 a month" from its training data is guessing. A bot that pulls the current price list and quotes it, with a link, is repeating something you published.

It is not only chatbots

A second German decision pushed in the same direction from a different angle. A Munich court held Google directly liable for false statements in its AI Overviews, on the reasoning that the overview is Google's own content rather than a protected list of somebody else's links.

Different defendant, different technology, same underlying move: when your system generates a statement instead of pointing at someone else's, you are the author. For support teams the read across is obvious. An AI written summary at the top of a knowledge base article is your content. A suggested reply that an agent sends without editing is your content. An auto generated release note is your content.

The comfortable distinction people draw between "the bot chatting" and "AI helping internally" gets thinner the moment the output reaches a customer unedited.

What your help desk should be logging

If a customer claims the bot promised them something, the argument is evidential, not philosophical. You need the transcript, and you need to know which lane produced the reply and what source it used.

That is close to what we argued about authorization records for AI agents, but aimed at a different question. That post asked whether the agent was allowed to take an action. This one asks whether it was allowed to make a claim, and what it based the claim on.

Keep the retrieved source alongside the answer, not just the answer. Six months later, "the bot quoted the policy page as it read on 3 March" is a defence. "The bot said something" is not.

If someone else built the bot

Plenty of support teams did not train anything. They switched on a feature inside a helpdesk product, or handed the channel to an outsourced provider. The ruling does not care much, because the operator is the one whose name is on the website.

That makes the contract worth a read you probably have not given it. Two questions matter more than the rest. Who decides what the bot may discuss, and can you change that scope yourself without raising a ticket with your vendor? If the answer to the second is no, you are carrying a liability you cannot directly control, which is a strange place to be.

Ask for the transcript export too. If your provider keeps conversations in a system you cannot query, your evidence lives on somebody else's retention schedule. That is fine right up until the week you need it.

A short exercise worth running this week

Take your twenty most common inbound questions. Sort them into the three lanes. My guess is that two or three currently sit in the free lane that should not, and that at least one of those is about money.

Then ask the bot the ten questions you would least like a customer to ask, in the rudest phrasing a frustrated person would use. Not the polished test set. The real ones. What comes back tells you more than any policy document.

Frequently asked questions

Does this ruling apply outside Germany?

Directly, no. It binds in its own jurisdiction and is under appeal. But the reasoning, that an operator controls the tool and therefore owns its output, is not unique to German law, and similar conclusions are appearing elsewhere. Treat it as a direction of travel rather than a foreign curiosity.

Does a disclaimer saying the bot may be inaccurate protect us?

On the facts of this case, careful configuration did not help, and a disclaimer is weaker than configuration. It may affect damages at the margins. Do not build your position on it.

Should we just turn the AI off?

No, and I would push back on anyone who suggests it. The ruling penalises unbounded scope, not automation. A bot confined to lookups and published sources is both useful and defensible.

What about a bot that only answers from our own documentation?

That is much the safer design, which is why the quote-only lane exists. The residual risk is a bot that retrieves the right document and then summarises it into something the document never said, so keep the source visible in the reply.

How long should we keep chat transcripts?

Long enough to cover the complaint window you realistically face, balanced against your data retention policy. The transcripts are the evidence, so deleting them early removes your own defence.

Related resources

ICTDesk runs the AI bot on your own content and keeps every conversation searchable, which is the combination this ruling rewards. If you are reviewing what your bot is allowed to promise, take a look at how ICTDesk handles it.

OCR Now Asks What You Fixed, Not Just What You Found

Tahir Almas — Wed, 16 Sep 2026 20:56:33 +0000

Originally published at ictfax.org

If you run your own fax server, you have probably done a risk analysis at some point. Maybe a spreadsheet, maybe a proper report. The question that matters in 2026 is different: after you wrote it, what did you actually change, and can you prove when?

The HHS Office for Civil Rights has widened its Risk Analysis Initiative to cover risk management as well. Same Security Rule, next subsection. It moves the audit from whether you looked to whether you acted.

Two rules, not one, and open source fax server software touches both

People talk about "the risk assessment" as a single obligation. It isn't. The Security Rule splits it in two, and they sit right next to each other at 45 CFR 164.308(a)(1)(ii).

Subsection (A) is risk analysis: identify the threats and vulnerabilities to your electronic protected health information. Subsection (B) is risk management: put in place security measures that reduce those risks to a reasonable and appropriate level. One finds the hole. The other fills it.

The two subsections sit together in the rule, but most teams only have paperwork for the first one.

Here is my honest read of why this hurts self hosted teams more than hosted ones. When you buy a fax service, somebody else owns the spool, the trunk and the archive, and their compliance team writes the remediation notes. When you host it yourself, you own all three, and the notes are yours to write. Nobody writes them.

What OCR expects to see in the file

The expectation is not a certificate. It is a paper trail that ties findings to actions and puts dates on both. In practice that means a risk register listing what you found across every system that creates, receives, maintains or transmits ePHI, and against each entry a record of what was decided, what was implemented, and when it closed.

For a fax stack, "every system" is wider than the application. The inbound spool holds images. The outbound queue holds images. The archive holds years of them. The SIP leg carries them across a network you may not control. Your database holds the metadata, which is often enough to identify a patient on its own.

Five rows, four closed, one open. The open row is fine as long as it has a decision and an owner.

Notice the last row is still open. That is not a failure. An unresolved finding with a documented decision behind it reads very differently from a finding nobody touched. What gets punished is silence.

The part teams get wrong

A risk analysis dated 2023 with no remediation trail after it is worse than no analysis at all, because it proves you knew. That sounds harsh, but it is the logic every enforcement summary follows. You identified a vulnerability, you documented it, and then nothing happened for three years.

The second mistake is scoping the analysis to the application and stopping there. If your T.38 fax transport runs unencrypted across a shared link, that belongs in the register whether or not the fax software itself is hardened. The rule follows the data, not the product boundary.

Third, and this one is specific to open source: people treat "we can read the code" as a control. It is an advantage, genuinely, because you can verify what happens to a fax instead of trusting a datasheet. But reading the code is not the same as writing down what you changed after you read it.

The metadata problem nobody writes down

Ask most teams where the PHI lives in their fax stack and they point at the image files. Fair enough, that is where the clinical content sits. But the database row describing that fax is frequently enough to identify someone on its own.

A row that says an inbound fax arrived from a named oncology practice, on a given date, addressed to a named patient, has told you something clinical before anyone opens the TIFF. Sender number, recipient, timestamp and subject line together are often identifying, and they are usually the least protected part of the system because they feel like plumbing.

Same story with logs. Debug logging on a fax gateway has a habit of capturing numbers and sometimes headers, then shipping them to a log aggregator that was never in scope for anything. If you run centralised logging, that aggregator belongs in the register.

I would put both in the risk analysis explicitly rather than assuming they are covered by a line about the application. Auditors read scope literally, and so should you.

What counts as a material change

The rule says reassess on material change, which sounds vague until you list what has actually changed on a fax server in the last two years. Most of these are obvious in hindsight and invisible at the time.

Swapping SIP providers changes the transport path and often the encryption posture. Moving from bare metal to containers changes where the spool physically lives and who can reach it. Adding a second site for redundancy doubles the number of places images rest. Turning on a new integration, even a read only one, adds a system that touches ePHI.

Staff changes count too, which teams almost never record. If the person who held the shared admin credential left in March and the credential still works in September, that is a finding with a date attached whether you wrote it down or not.

My rule of thumb: if you would mention it in a change log, it is material enough to note in the register. One line is fine.

A workable cadence for small teams

You do not need a compliance department. You need a file that someone updates when things change. Start the register with the systems that actually hold images, add the transport, add the metadata store, then work down.

Re-check when something material changes, and at least once a year even when nothing does. A migration counts. A new trunk provider counts. Moving the archive to different storage definitely counts. If you have just moved to a container deployment, that is a material change and the register should say so.

Keep it boring. A dated table in a repository beats a polished document nobody opens. The audit value is in the dates, not the formatting.

Where ICTFax fits

ICTFax is open source, so the parts you need to write about are inspectable rather than assumed. You can state where images sit on disk, which transport carries them, and what the retention job does, because you can read it. That makes the register easier to fill honestly.

Self hosting also means the remediation is yours to schedule rather than something you wait on a vendor for. If the finding is an unencrypted spool, you can close it this week. Have a look at the installation guide if you are standing up a fresh deployment and want the storage and transport decisions recorded from day one.

Frequently asked questions

Does a risk analysis expire?

There is no fixed expiry date in the rule. The expectation is that you reassess on material change and periodically regardless. Most teams settle on annually plus after any significant infrastructure change, which is a defensible reading.

Is risk management a separate document from risk analysis?

It does not have to be. A single register with a remediation column works fine, and is easier to keep current than two files that drift apart. What matters is that findings and actions are linked and dated.

We are a small practice. Does this really apply to us?

Yes. The rule scales in how you implement it, not in whether it applies. A four person practice can satisfy this with a short table. The obligation is the same, the effort is not.

What if a finding is still open when an audit lands?

Open findings are normal. Show the decision, the planned measure and the reason for the timeline. An open item with a documented plan is a very different conversation from one with no record at all.

Does using open source fax server software make compliance harder?

Harder in that nobody else writes your documentation. Easier in that you can verify what the software actually does with PHI rather than taking a vendor's word for it. On balance I would take the verifiability.

Related resources

If you are reviewing your fax path this quarter, start the register before you start the hardening. The register is what you will be asked for. ICTFax is free and open source, so you can inspect every step a fax takes and write the entries from what the code does rather than from what a brochure claims.

Is Your AI Chat About Your Case Private? Three Courts Gave Three Answers

Tahir Almas — Sun, 13 Sep 2026 05:19:42 +0000

Originally published at roshni.online

If you have typed the details of a dispute into an AI chatbot, you probably assumed that conversation was yours. Three US federal courts looked at that assumption in early 2026 and reached three different answers. In one case prosecutors were allowed to read the chats. In two others, the person's queries were protected. The difference was not the technology.

None of this is legal advice, and I am not a lawyer. But you do not need to be one to take the practical lesson, which is simpler than the case law: what you type to a general chatbot is not automatically private, and you get to decide what goes into it.

What the three courts decided

The one that got attention was United States v. Heppner, decided in the Southern District of New York on 17 February 2026 by Judge Jed Rakoff. A criminal defendant who had his own lawyer used a consumer AI assistant on his own initiative to work through material about his case. The court held that none of it was protected.

The reasoning had four parts. The assistant is not an attorney. Its privacy policy permitted the company to share what he typed with third parties, so he had no reasonable expectation of confidentiality. He had not used it at his lawyer's direction. And the outputs did not reflect his counsel's strategy, so they were not work product either. Prosecutors got to use them.

A week earlier, a magistrate judge in the Eastern District of Michigan had gone the other way. In Warner v. Gilbarco, decided 10 February 2026, the plaintiff had no lawyer. The court held that her queries and the answers she received were her work product, on the reasoning that these systems are tools rather than people, so using one is not the same as telling a stranger about your case.

Then on 30 March 2026 the District of Colorado sided with Warner. In Morgan v. V2X Inc. the court held that work product protection covers material a self-represented litigant prepares, and set Heppner aside as a criminal case governed by different rules. It attached a condition, though: she had to disclose which AI tool she had used.

What actually separates them

Read together, a few things seem to matter. Whether the case is civil or criminal. Whether you have a lawyer, and whether you were acting on their instructions. And, in Heppner at least, what the product's own privacy policy says the company may do with what you type.

That last factor is the one most people never check, and it is the one you have the most control over. A court asked whether the defendant could reasonably have expected privacy, then read the terms he had agreed to and concluded that he could not.

I would not read any of this as settled. Three decisions in seven weeks, pointing in two directions, is the early stage of a question, not the end of one. If someone tells you confidently that AI chats are private, or that they definitely are not, they are ahead of the law.

There is a second risk, and it bites harder

Privacy is not the only way AI goes wrong in a legal matter. The bigger everyday problem is that these systems invent case names, quotes and citations that sound completely ordinary and do not exist.

Courts have been dealing with this for two years now, and the trackers that follow these cases show most of them involve people representing themselves. That makes sense. A self-represented person has no colleague to check the citation with, and no instinct that the case name looks slightly off.

Florida decided to do something about it. Rule 2.515(d)(2), effective 15 June 2026, requires whoever signs a filing to represent that the legal authorities identified exist and are accurately cited. It applies to attorneys and to self-represented litigants equally, and the court can respond to a filing inconsistent with that representation with a reprimand, contempt, striking the document, dismissal, costs or fees.

Notice what the rule does not do. It does not ban AI, and it does not ask you to disclose that you used it. It asks you to stand behind your citations, which was always the deal. The rule just says it out loud now because enough people forgot.

How to use AI for legal guidance without handing over your case

Here is the sorting question I would use, and it takes two seconds. Am I asking how something works, or am I telling it what happened to me?

General questions are fine. What a notice period usually means, how small claims works, the difference between two forms you have been handed, what a clause is trying to do. You are learning vocabulary so that the next conversation goes better, and none of it is evidence about you.

Your own facts are a different thing. Names, dates, amounts, the employer, what you said in the argument, what you signed. That material belongs with somebody who owes you a duty of confidence. A general chatbot owes you nothing of the kind, and as the three rulings show, whether the transcript stays yours is currently a coin toss that depends on a court you have not met yet.

If you are going to use AI anyway, and most people will, three habits cover most of the risk. Strip the identifying details before you paste anything. Keep a note of which tool you used and when, because a court may ask, as Colorado did. And check every case name and every quote against a real source before it goes anywhere near a filing.

Where a free AI assistant still earns its place

I do not want this to read as an argument against using AI for legal guidance, because it is not. Most people who need legal help do not have a lawyer and are not about to hire one for a question about a tenancy notice. Telling them to stay off AI is telling them to stay confused.

The useful role is the first twenty minutes. Working out what kind of problem you have, what the words mean, what questions to bring to a person. That is genuinely valuable and it costs nothing, which is why Roshni's free AI assistant exists and why it is deliberately separate from the conversations you have with a professional.

What it is not is a stand-in for a consultation. The design point we keep coming back to, on the mental health side as much as the legal one, is that an assistant should know when to hand you over. A tool that will happily draft your court filing is not being helpful, it is being agreeable.

When you do move to a person, that conversation sits under a professional duty of confidence rather than a product's privacy policy. That is the whole difference, and it is worth understanding before you decide where to type the hard part.

FAQ

Are my ChatGPT or AI assistant chats protected by attorney-client privilege?

Not on their own. Privilege attaches to communications with a lawyer for the purpose of getting legal advice. An AI assistant is not a lawyer, which is exactly what the court said in Heppner. Two other courts protected a self-represented person's chats under the separate work product doctrine, which is a different and narrower thing.

Does it matter whether I have a lawyer?

It seems to. Both of the rulings that protected the chats involved self-represented litigants in civil cases. The ruling that did not involved a defendant who had counsel and used the tool without their direction. If you have a lawyer, ask them before you put case material into any AI tool.

Can I be sanctioned for using AI in a court filing?

You can be sanctioned for citing authorities that do not exist, whether AI produced them or not. Florida's Rule 2.515(d)(2) makes that explicit from 15 June 2026 and applies it to self-represented litigants as well as lawyers. Check every citation yourself before you file.

Will I have to say I used AI?

It depends where you are. Florida's rule asks you to certify your authorities are real, not to disclose the tool. The Colorado court did require the litigant to identify which AI tool she had used. Keeping a simple record of tool and date costs you nothing and answers the question if it comes.

What should I never put into a general chatbot?

Anything you would not want the other side reading. Full names, addresses, account numbers, the text of an agreement, medical details, and your own account of events. Ask the general version of your question instead, then take the specifics to a person.

Is Roshni's AI assistant different?

It runs on our own infrastructure rather than a third party API, and the assistant conversation is kept separate from your consultations with a professional. That said, the honest answer to "is this privileged" is still no, because an assistant is not a lawyer anywhere. Use it to get oriented, then book the consultation for your facts.

If you have a legal question you have been circling for weeks, start a free chat to get your bearings, then talk to a verified professional about the part that is actually yours.