You're allowing your ticketing tool to drive your process, rather than using a set of tool to support a functional and well-defined process that already works smoothly. Don't do that!
Agile Frameworks Require Self-Managing Teams, Not Tickets
You're trying to force a workflow based on ticket assignment onto an agile process. It works poorly. Absolutely no one who understands Scrum or Lean principles would find this outcome surprising.
If you must use ticketing (which I refuse to accept a priori) then tickets should be pulled by teams rather than assigned to people. Scrum and Kanban in particular are pull queues; work is pulled from one activity to another as work-in-progress limits permit. They are never pushed or assigned from on person to another.
Adapt your tool to the real workflow, or toss the tool and find one that supports your workflow. Doing anything else is asking for trouble.
Why Have Three Teams?
If you have 7-9 people spread across three "teams," they should really be a single cross-functional team. If you have 7-9 people per team, then Scrum is not a good fit by itself. You should be looking at a scaled agile implementation such as Nexus, which provides a fourth integration team for each collective Increment.
You should also not be defining and assigning tickets to teams or people. Scrum requires self-managing teams, so each team need to understand the Increment being built, have a cohesive Sprint Goal, and a clear Definition of Done. The Product Owner should define what needs to be built, and leave it to the teams or team members to determine how best to build it.
A lot of your question would resolve itself if you let the team members determine how and where they need to integrate with one another. This won't happen on day one; you need to give the process time to evolve, so that the team(s) can learn how to work together in the most efficient way possible.
Collaboration and Test-First Development
The fact that you think of front-end, back-end, and AI work as distinct is a problem, too. Unless you have a solid Definition of Done and executable tests at the beginning of the work before a single line of code is written, how will anyone know if they've built the right thing? Instead, the consolidated team or multiple teams need to work together to define what should be built, how they will know it's been built right, and collaborate from the very beginning of the iteration to ensure that they are all working towards the same objective for the iteration. In Scrum, this is the Sprint Goal.
Tossing stuff over the wall to one another is not the way to make this happen. Instead, the team or teams should be working together from the beginning. For example, if the front-end team needs to have an API endpoint to get data from the back end, and the back end needs some bit of AI code to return the correct result through the API, then these are not distinct tasks. They represent a single Increment that needs to be coordinated across three closely-related skills sets and activities, and that requires active collaboration.
If you're going to have specialists, they need to collaborate and coordinate. You can't simply have them work independently and expect the edges of what three separate teams are building to join together smoothly. Build in a collaborative process and a swarming mindset from the beginning, and you'll find the work flows a lot smoother.